Skip to content

Releases: sync endpoint skips the settle window for one named version - #84

Merged
adamshiervani merged 1 commit into
devfrom
fix/release-sync-scope-settle
Sep 19, 2026
Merged

adamshiervani merged 1 commit into
devfrom
fix/release-sync-scope-settle

Conversation

@adamshiervani

@adamshiervani adamshiervani commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

POST /releases/sync turned the settle window off for every version in the bucket. A call made while a different upload was still running registered that upload half done, and sync never revisits a row. Now the body names the one version the caller finished, and only that version skips the window.

POST /releases/sync
{ "type": "mini", "version": "0.5.3" }   → 0.5.3 skips the settle window, all else keeps it
(no body)                                → a normal tick, settle window on
{ "type": "mini" }                       → 400, type and version go together
{ "type": "firmware", "version": "1" }   → 400, unknown release type
 createRelease(type, version)
   collectReleaseArtifacts
-  if uploadSettleMs
+  if uploadSettleMs and not (config.settled is this type+version)
     newest object < window ago → "uploading", retry next tick
   decide → create @10%
 src/release-sync.ts
+  SyncConfig.settled?: { type, version }
-  runner(options: Pick<SyncConfig, "uploadSettleMs">)
+  runner(options: Pick<SyncConfig, "settled">)
 src/releases.ts
+  syncBodySchema                 # zod, both fields or neither, type ∈ OTA_PREFIXES
+  parseOrBadRequest(schema, input)   # parseQuery now delegates to it
   Sync: runner({ settled })

The upload script sends the type and version it just wrote. A bare call is still useful as "run the tick now".


Note

Medium Risk
Changes which R2 versions get registered in the DB during sync; mis-specified type/version could delay the intended release, but the change reduces risk of freezing partial uploads.

Overview
POST /releases/sync no longer disables the upload settle window for every version in the bucket. Previously the handler forced uploadSettleMs: 0, so a post-upload sync could register another version that was still uploading (sync never revisits rows). The endpoint now accepts an optional body { type, version }; only that release skips the settle check while all other candidates still defer if objects changed recently.

SyncConfig gains settled?: { type, version }, createRelease applies the settle gate only when the version is not vouched, and ReleaseSyncRunner options pass settled instead of overriding uploadSettleMs. Request validation uses a new Zod syncBodySchema (both fields required together, type must be in OTA_PREFIXES); invalid bodies return 400 without running sync. A body-less call still triggers a normal tick with the full settle window.

Reviewed by Cursor Bugbot for commit 401c2e2. Bugbot is set up for automated code reviews on this repo. Configure here.

The endpoint turned the settle window off for every version in the
bucket. A call made while a different upload was still running
registered that upload half done, and sync never revisits a row.

The body now names the version the caller finished, and only that
version skips the window. Without a body the call is a normal tick.
@adamshiervani
adamshiervani requested a balanced review from Copilot September 19, 2026 13:18
@adamshiervani
adamshiervani marked this pull request as ready for review September 19, 2026 13:19
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 19, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-09-19T13:21:53.683857Z 401c2e2 Draft marked ready
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟢 Approval recommended

The implementation matches the stated endpoint contract and has focused coverage for its key behaviors.

Review effort: Balanced
Findings: None

What changed in this PR

Scopes settle-window bypasses to the explicitly completed release version.

Changes:

  • Adds validated optional { type, version } sync input.
  • Applies bypass only to the matching release.
  • Tests targeted, bodyless, invalid, and busy requests.
File Description
src/​release-sync.ts Adds targeted settle-window bypass configuration.
src/​releases.ts Validates and forwards optional release identity.
test/​sync-releases.test.ts Covers the updated sync behavior.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@adamshiervani
adamshiervani merged commit 6d5da4f into dev Sep 19, 2026
4 checks passed
adamshiervani added a commit that referenced this pull request Sep 19, 2026
* fix(releases): serve staged releases before any release reaches 100% (#78)

A prefix with no release at 100% made the default lookup throw a 500
before eligibility was checked, so no device got the staged build. That
is every device for a new prefix until its first release is fully
rolled out, and every JetKVM device the day no app or system row sits
at 100%.

The default lookup now returns null when nothing is at 100%. A device
inside the rollout bucket gets the staged release as before; a device
outside it gets a 404 saying no release is rolled out yet for its SKU,
instead of a 500.

Found by Bugbot on the release PR (#77).

* Releases: sync new R2 releases from the API every 30 minutes (#81)

* feat(releases): sync new R2 releases from the API every 30 minutes

The release sync only ran when an operator invoked scripts/sync-releases.ts
by hand, so a firmware upload sat in R2 until someone remembered to run it.
The API process now runs the same sync on start and every 30 minutes,
registering each new stable version at the default 10% rollout.

The non-interactive core (bucket listing, artifact collection, DB insert)
moves from the script into src/release-sync.ts so the API can import it;
the script keeps the GPG check and the confirmation prompt and passes them
in as the release decider. Both entry points share one R2 client via src/s3.ts.

Scheduled runs skip a tick while the previous run is still going, log and
survive a failed run, and treat a unique-constraint hit on insert as
"already synced" so several API instances can race without an error.
The existence check now precedes the R2 artifact walk, so a tick over an
already-synced bucket costs one list call per prefix plus one DB lookup per
version.

* fix(release-sync): defer versions whose upload is still settling

A scheduled tick can land while a version is still being uploaded and
register it with a partial SKU set or a hash that changes afterwards. Sync
never rewrites a row, so that snapshot would be permanent.

Before collecting artifacts, list every object under the version folder
and skip the version when the newest object changed in the last 10
minutes. The window is shorter than the schedule interval, so a real
upload costs at most one extra tick.

* refactor(release-sync): share R2 config, paginate via SDK, probe SKUs concurrently

* src/s3.ts now exports bucketName and baseUrl next to the client, so the
  request handlers, the scheduler and the script read R2 config from one
  place instead of three.
* The upload settle window moves into SyncConfig.uploadSettleMs. The
  scheduler sets it; the one-shot operator script leaves it unset because an
  operator sees the artifact list before confirming and has no next run.
* newestUploadTime uses the SDK's paginateListObjectsV2 instead of a
  hand-rolled continuation loop.
* collectReleaseArtifacts probes SKUs concurrently and folds the results in
  SKU order, so artifact order and the primary artifact are unchanged.
* Tests drop empty per-prefix listing stubs that the file-level default
  already covers.

* fix(release-sync): take the settle listing after the artifact scan

Listing the version folder before the scan left a gap: an upload that
started between the listing and the scan passed the check and was captured
partially. Listing after the scan closes it, because any upload active
during the scan leaves an object newer than the window and the snapshot
is discarded instead of registered.

* fix(release-sync): paginate the version listing

ListObjectsV2 returns at most 1,000 common prefixes per page. Once a
release prefix grows past that, versions on later pages were never seen
on any tick. listStableVersions now walks every page with the SDK
paginator, as newestUploadTime already does, and the mock in the sync
tests can serve a truncated listing.

* Release sync: a unique violation is only a race when the row exists (#82)

* fix(release-sync): only treat a unique violation as a race when the row exists

Sync caught every P2002 from the release insert as "created concurrently
elsewhere". On staging the id sequences were behind the rows after a data
import, so each insert failed on the primary key, was logged as a race, and
left nothing in the table.

After a unique violation, createRelease now looks the (version, type) row
up. Present means another instance registered it first; absent means the
insert really failed, and the error is rethrown with the type and version
in its message so the scheduled run log names the release.

* fix(release-sync): name the release in every per-version failure

Wrapping only the insert error left the row lookup, and the S3 scan
before it, free to escape without the type and version. syncReleases now
wraps whatever createRelease throws for a version.

* feat(releases): POST /releases/sync for the upload script (#83)

The scheduled tick found a new version at most 30 minutes plus the settle
window after upload. The upload script knows when its last object is
written, so it can trigger the sync itself.

One runner now owns the in-progress flag and serves both the timer and
the endpoint. The endpoint is guarded by RELEASE_SYNC_TOKEN as a bearer
token, compared in constant time, and is not registered without it. It
runs with the settle window off and answers with the per-outcome counts,
or 409 while a run is in progress.

* fix(auth): accept the bearer scheme in any case (#85)

Scheme names are case-insensitive (RFC 9110). The token is still
compared exactly.

* fix(releases): scope the sync endpoint's settle bypass to one version (#84)

The endpoint turned the settle window off for every version in the
bucket. A call made while a different upload was still running
registered that upload half done, and sync never revisits a row.

The body now names the version the caller finished, and only that
version skips the window. Without a body the call is a normal tick.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants