[BUG] Can't publish update to existing package

[savetheclocktower]

Is this Bug Present in the upstream API Server?

• Yes
• No
• Unsure

What is the Bug
When I try to publish a new version of savetheclocktower/calculator-light-ui via ppm publish patch, I get the message Creating new version failed: The package.json at owner/repo isn't valid..

Via logging, I can ascertain that ppm is getting as far as making an API request to https://pulsar-edit.com/api/packages/calculator-light-ui/versions, but one of the tasks that occurs on the backend during that request is apparently throwing a "Bad package" error.

Quoth @confused-Techie on Discord:

So it seems for some reason your ownerRepo string isn't being passed to the git module correctly. Not quite sure why, but testing the values it would've used from your package on the DB works for me manually, so I'm not totally sure where exactly it's coming from but thanks for calling attention to it

How to Replicate the Bug

Be me, @savetheclocktower, and try to publish a new version of calculator-light-ui.

OK, seriously: I don't know if this is happening for anyone else, nor have I tried to publish new versions of any of my other packages yet.

[savetheclocktower]

Just tried publishing a trivial change to savetheclocktower/atom-inline-autocomplete-textmate with the same result, so it's not just one package for me.

[confused-Techie]

To help myself work this out later, here is a stripped down log from the backend server during this request.

POST 400 414B 612 ms /api/packages/calculator-light-ui/versions?tag=v0.3.15
[TRACE]:: auth.verifyAuth() Called in Production instance
[INFO]:: auth.verifyAuth() Returning Authenticated User: savetheclocktower
[TRACE]:: savetheclocktower Attempting to publish a new package version
[WARNING]:: Failed to Get from GH for package.json. Err: Error: Not Found
[TRACE]:: Unable to get Package JSON from git with:
HTTP:: <REDACTED> [2023-02-04T21:12:19:038Z] "POST /api/packages/calculator-light-ui/versions?tag=v0.3.15 https" 400 608ms

A note here about the logs, we can see where it says Failed to Get from the logs are supposed to be Failed to Get ${repo} from

So this means in getPackageJSON() of git.js#557 the repo is failing to be passed through. The repo is taken from the versions meta data after

const packExists = await database.getPackageByName(params.packageName, true);

....

const meta - packExists.content?.versions[0]?.meta;

...

let ownerRepo = utils.getOwnerRepoFromPackage(meta);

const packJSON = await git.getPackageJSON(ownerRepo, user.content)

Then the following is the signature from git

async function getPackageJSON(repo, user) {
  try {
    const res = await suepragent
      .get(`${GH_API_URL}/repos/${repo}/contents/package.json`)
  } catch(err) {
    // This is where our logging occurs, meaning the API request is failing since we don't have a repo
  }

[savetheclocktower]

I futzed around a bit and I think I know what's going on.

During the process of creating a new version of an existing package, the backend calls git.metadataAppendTarballInfo. It explicitly passes the version from package.json as the second argument.

This range represents as far as I get into metadataAppendTarballInfo. Since repo (second argument) is a string, we call getRepoTags with a version string as the first argument.

The name of the variable should've been a clue already, but when we get into getRepoTags, it's clear what's gone wrong. The first argument is assumed to be a user/repo combo, not a version string. A request is made to https://api.github.com/repos/0.2.19/tags, which is obviously not what it should be requesting.

I just started hacking on this today, so I'm not sure what the best fix is, but this makes me wonder how any packages are being updated.

[confused-Techie]

Good investigative work. These changes could be a regression on our end.

The best fix for this really is already written over in #50

As this whole section of code is rewritten there now knowing what we know.

So if this is truly the case that means that nothing can be updated right now, which isn't ideal

[savetheclocktower]

I can confirm that when I check out #50 locally and try the same thing, I get as far as an authentication error — which is to be expected. So I agree that #50 is likely to fix this.

[confused-Techie]

I've gone ahead and pushed the changes in #50 (and all other PR's merged from then to today) live in production.

It is still missing some of the new testing features I wanted, but there were other fixes that needed to be pushed out, so I've bit the bullet.

So we will get to find out if hopefully this works. Feel free to let me know or wait until the next tagged version which will happen once all testing changes I've been hoping for are made.

[savetheclocktower]

OK, now I'm getting this:

Creating new version failed: That repo does not exist, isn't an atom package, or atombot does not have access.

Edit: Same error on another of my packages.

[confused-Techie]

So while there still is a bug about publishing, since it is a major improvement over this one, I'll go ahead and close this issue.

Your contributions are greatly appreciated, thank you!

PS. As for the current issue that effects this I've pinned the issue for greater visibility