build(deps-dev): bump rollup from 3.17.2 to 3.17.3 - #898
Merged
Conversation
Bumps [rollup](https://github.com/rollup/rollup) from 3.17.2 to 3.17.3. - [Release notes](https://github.com/rollup/rollup/releases) - [Changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md) - [Commits](rollup/rollup@v3.17.2...v3.17.3) --- updated-dependencies: - dependency-name: rollup dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
tada5hi
added a commit
that referenced
this pull request
Aug 13, 2026
* chore(deps): update rapiq packages to v2.1.0
Bumps @rapiq/{core,codec-url,parser-mongo,adapter-memory,adapter-sql,
adapter-typeorm} from ^2.0.0 to ^2.1.0.
The release carries a third change beyond its two headline features:
tada5hi/rapiq#906 makes `sorts` the canonical spelling on every
developer-authored surface. Two consequences had to be handled.
`describe()` renamed its `sort` key to `sorts` and, unlike the build
input / schema option / Schema property surfaces, kept no deprecated
alias. That description is served verbatim as `meta.schema`, so the
rename is wire-visible for API consumers. The URL parameter is
unchanged (`?sort=-name`).
The entity collection manager decided whether a load supersedes the
retained interactive sorts by testing `'sort' in input`, so a load
carrying the now-canonical `sorts` was silently dropped. It accepts
both spellings, matched on a DEFINED value rather than key presence:
rapiq documents `{ sorts: props.sorts, sort: props.sort }` as a safe
spread wrapper, and that shape carries both keys as `undefined`, which
a presence test reads as "supplied" and would wipe the retained sorts.
`indexed-invariant.spec.ts` reported green throughout the bump while
checking nothing: it iterated `description.sort?.allowed || []`, which
the rename turned into `undefined`, so the loop never ran and the
"every allowed sort key leads an index" invariant silently stopped
being enforced. Re-pointed, and guarded against passing vacuously
again. The invariant itself still holds.
* refactor: use the canonical rapiq sorts spelling
rapiq 2.1.0 (tada5hi/rapiq#906) renamed the sort key to `sorts` across
every developer-authored surface, keeping `sort` as a deprecated alias
slated for removal in 3.0. Migrates all authored uses: the 25 entity
schema declarations plus the query build inputs in the kit components,
the admin console and the account console.
The wire parameter is deliberately untouched. A query string still
carries `?sort=-name`, so the parse-input spellings in the decode specs
stay as they are, alongside the sibling `filter` and `page` wire names.
The collection manager keeps reading the deprecated key too. That is
not authup authoring deprecated syntax, it is tolerating it from
callers: rapiq still declares `sort` on QueryBuildInput, so dropping
the branch would silently discard a consumer's sorts.
* refactor(server-core): adopt the upstream schema index assertion
`assertSchemaIndexesMatchEntity` existed because
`assertSchemaMatchesEntity` did not cover a schema's `indexes`
declaration. rapiq 2.1.0 folded that check upstream (tada5hi/rapiq#902
closed #898), and `validateEntitySchemas` already calls the upstream
assert on the line above, so the local copy was duplication.
Upstream applies the same leftmost-prefix rule over the same primary
key, unique and index structures, and is stricter in two ways: it
resolves columns by property PATH, so embedded columns compare
correctly, and it additionally rejects an index naming a column the
entity does not have. It reports a typed SchemaEntityIndexMismatchError
instead of a bare Error.
The two tests are re-pointed at the upstream function rather than
dropped, so the boot guarantee stays pinned locally.
* fix(server-core): mint one key per realm and use under concurrency
`resolveOrCreate` is check-then-act: it looks for an active key, counts
existing rows, then inserts. Nothing made that atomic, so every
concurrent caller for one (realm, use) observed zero rows and inserted
its own key.
The callers are hot paths. The token signer resolves a signature key
for EVERY issuance and the realm cipher an encryption key for every MFA
seed, so two simultaneous logins into a freshly created realm each
minted a key. A new spec reproduces it deterministically: three
concurrent resolves produced three keys.
Concurrent mints now share a single in-flight promise, and the guarded
section re-reads before inserting, because a caller's lookup may
predate a mint that has since completed and left the map.
The map lives on the adapter instance, so it is scoped to one
application and two applications in one process never share mint state.
That scoping is also why ProvisionerModule now prefers the registered
KeyStore over constructing its own adapter, falling back only in the
minimal module graphs that never register one: a second instance
carries a second map, so the startup backfill and a concurrent
realm-create request would each still mint.
Separate processes can continue to race. The duplicate is tolerable
rather than fatal, since both keys are published in JWKS and verify and
selection is deterministically ordered, so this deliberately stops
short of a distributed lock.
* test(server-core): pin mint recovery after a failed key mint
The in-flight guard would be worse than the race it fixes if a rejected
mint stayed in the map: every later caller would receive the same
rejected promise and the realm could not mint again until the process
restarted. Covers the kill-switch rejection arriving on concurrent
resolves, and that a later resolve still succeeds.
* test(server-core): check the described query blocks per schema
The vacuity guard flattened every schema's allow-list into one array, so
a single schema losing its `filters` or `sorts` block stayed invisible:
the other schemas kept the count positive while the invariant loops'
`|| []` silently skipped the one that had gone missing. It now asserts
the block per schema and reports which schema lacks it.
Non-emptiness is deliberately NOT asserted per schema. An absent
allow-list is legitimate — `clientScope` declares no sort vocabulary, so
its `sorts.allowed` is null by design and a per-schema non-empty
assertion would fail against it. A separate aggregate check keeps the
loops from running over nothing at all.
Also corrects the architecture note, which still described the sort
override as testing key presence after it moved to a defined-value test.
Reported by CodeRabbit on #3431.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps rollup from 3.17.2 to 3.17.3.
Release notes
Sourced from rollup's releases.
Changelog
Sourced from rollup's changelog.
Commits
d7cbebd3.17.3fa4e9a5Fix transformation ofimport.meta.urlin CommonJS (#4875)0e4d534Improve test stability (#4878)a9de15dfix: wrong params of the transform hook (#4876)cb64e1afix: style optimization in dark mode (#4870)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)