Does submitting a new version reset your position in the review queue?

Currently I am seeing long review times for our extension. Review time seems to be at least 2 weeks compared to 1-2 days for Safari and Chrome.

The issue is that we typically release 1-2 updates per week. I am wondering what the best practice is in this case?

When I submit a new version, previous un-reviewed versions get disabled. Does that mean submitting a new version reset your position in the review queue?

If yes, is it recommended to skip versions for Firefox users? I am afraid that I am stuck in a loop where my position keeps getting reset to the bottom of the review queue because we are providing frequent updates to users.

1 Like

Hey @kepano! In the scenario you described, the new submission will take the place of the old one.

But aren’t extensions that waits already over a week specially marked for the reviewer so that he can focus on those first?

And if you release new version, it will appear as “freshly submitted” so reviewer will focus instead on those that have been waiting for longer…
(I’m only guessing here)

@juraj.masiar, what you described is essentially a first in first out queue, and yes, that’s the core of how the review queue works: older items are processed first, new items get added to the end of the queue.

But, I think you might be imagining this as a queue of submissions when it is more accurate to think of it as a queue of add-ons to review.

When a developer submits a new version for review, the extension gets added to the end of the review queue. Later, if the developer submits a new version while the extension is still queued, the extension’s queue record is updated to reference the newer version. The overall queue position remains the same, but the content being reviewed has changed. When the add-on is reviewed, it’s removed from the queue.

1 Like

Thanks for the info!
Since it’s not written anywhere, I can only use my imagination :slight_smile: .

And was imagining:

select * from submissions order by upload_date

And what you are saying sounds like:

select * from submissions order by id

Right? :slight_smile:

Not quite. order by id implies that the queue is processed alphabetically by ID.

I think it’s a little easier to see how it works in script rather than a single query. Here’s my rough mental model:

interface AddonVersion {
  addonId: string;
}

interface QueueEntry {
  addonId: string;
  version: AddonVersion;
}

const reviewQueue: Array<QueueEntry> = [];

function submitVersionForReview(version: AddonVersion): void {
  const prevQueueEntry = reviewQueue.find(entry => entry.addonId === version.addonId);
  if (prevQueueEntry) {
    // Add-on IS queued, update the existing entry to this version
    prevQueueEntry.version = version;
  } else {
    // Add-on is NOT queued, create a new entry that references this version
    const newQueueEntry: QueueEntry = {
      version,
      addonId: version.addonId,
    };
    reviewQueue.push(newQueueEntry);
  }
}

function getNextAddonForReviewer(): QueueEntry | undefined {
  return reviewQueue.shift();
}

Haha :smiley: .

I meant like a new table review_jobs where id is auto-incremented integer and addon_id would be a foreign key for addons table.
So when you sort by id, you’ll get the FIFO stack :slight_smile: .

Spoken like someone that is good at SQL :stuck_out_tongue_winking_eye: