Skip to content

chore(release): 0.3.2-unstable.20260828135101 - #1426

Closed
github-actions[bot] wants to merge 1 commit into
developmentfrom
release/v0.3.2-unstable.20260828135101
Closed

chore(release): 0.3.2-unstable.20260828135101#1426
github-actions[bot] wants to merge 1 commit into
developmentfrom
release/v0.3.2-unstable.20260828135101

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Version bump for 0.3.2-unstable.20260828135101, opened by the release workflow.

The tag v0.3.2-unstable.20260828135101 already names this commit, so the released
package and its label agree. Merging this brings development up
to the released version.

Raised as a pull request rather than pushed directly because
development requires one; a direct push is rejected with GH013
and takes the release down with it.

@github-actions

Copy link
Copy Markdown
Contributor Author

Superseded by the version bump for 0.3.2-unstable.20260828181008. The version this pull request carries is already published under its own tag; development catches up via the newer bump.

@github-actions github-actions Bot closed this Aug 28, 2026
auto-merge was automatically disabled August 28, 2026 18:12

Pull request was closed

@github-actions
github-actions Bot deleted the release/v0.3.2-unstable.20260828135101 branch August 28, 2026 18:12
rubenvdlinde added a commit that referenced this pull request Sep 5, 2026
…ng (#1848)

The seed verified its required schemas against a paged listing and treated
absence-from-the-page as absence-from-the-instance. On a shared instance
holding 1,997 schemas a `_limit=1000` request returns the first page, and a
slug that fell off it reads exactly like a slug the import never created.

That failure mode is worse than a wrong answer: the message names the import as
the culprit, so the obvious next move is to debug an import that worked
perfectly. It cost a full seed-and-suite cycle on stackiq before I thought to
count the rows.

Two changes:

  - Raise the page to 10,000 schemas and 2,000 registers.
  - Compare `len(items)` against the response `total` and REFUSE when they
    differ, rather than judging a population from a page.

The second matters more. A limit that is generous today is not generous
forever, and the next person to grow this instance should get "the listing is
truncated, raise the limit" instead of a fabricated missing slug.

Found by sweeping every ci-seed.sh in the fleet after hitting it twice:
opencatalogi (#1426) and stackiq. Four more were paging at 1000 against 1997,
and shillinq had headroom today but no guard.
rubenvdlinde added a commit that referenced this pull request Sep 6, 2026
* fix(e2e): the seed must refuse a truncated listing, not call it missing

The seed verified its required schemas against a paged listing and treated
absence-from-the-page as absence-from-the-instance. On a shared instance
holding 1,997 schemas a `_limit=1000` request returns the first page, and a
slug that fell off it reads exactly like a slug the import never created.

That failure mode is worse than a wrong answer: the message names the import as
the culprit, so the obvious next move is to debug an import that worked
perfectly. It cost a full seed-and-suite cycle on stackiq before I thought to
count the rows.

Two changes:

  - Raise the page to 10,000 schemas and 2,000 registers.
  - Compare `len(items)` against the response `total` and REFUSE when they
    differ, rather than judging a population from a page.

The second matters more. A limit that is generous today is not generous
forever, and the next person to grow this instance should get "the listing is
truncated, raise the limit" instead of a fabricated missing slug.

Found by sweeping every ci-seed.sh in the fleet after hitting it twice:
opencatalogi (#1426) and stackiq. Four more were paging at 1000 against 1997,
and shillinq had headroom today but no guard.

* fix(e2e): give the fixture sweep a teardown budget that fits it

`cleanupRunObjects()` is a NETWORK walk over every entry in FIXTURE_SCHEMAS
plus the trash, so its cost scales with that list — ten schemas — and not with
what the spec actually created. On a loaded instance it does not fit the 30s
the config allows a hook, and the run fails with `"afterAll" hook timeout of
30000ms exceeded`.

That message points at whichever spec finished last rather than at the sweep,
which is why it reads as a broken test. The assertions had already passed; only
the cleanup ran out of budget.

Raised inside the helper rather than in playwright.config.ts on purpose. The
config `timeout` governs every TEST as well as every hook, so lifting it there
would hide a genuinely slow test. This widens only the teardown that is
genuinely slow, and it fixes all 21 call sites at once instead of 21 edits.

Guarded with try/catch: `test.setTimeout()` throws when called outside a
running test or hook, and this helper should not become the reason a future
non-test caller breaks.

Verified on a 19-app instance: demo-caseload's 'a seeded task opens on its own
detail page' failed on the afterAll hook before, passes after.
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.

0 participants