Skip to content

chore(deps): bump rift engine to 0.24.0 and write behaviors the way it admits them - #346

Merged
EtaCassiopeia merged 3 commits into
masterfrom
chore/bump-rift-0.24.0
Oct 27, 2026
Merged

EtaCassiopeia merged 3 commits into
masterfrom
chore/bump-rift-0.24.0

Conversation

@EtaCassiopeia

@EtaCassiopeia EtaCassiopeia commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

Pins the engine to rift 0.24.0: natives, version preflight and the Testcontainers default image.

What 0.24.0 broke and how this fixes it

rift 0.24.0 aligns behaviors with Mountebank, and three shapes the SDK wrote are now ignored or refused:

Shape the SDK wrote 0.24.0 Now written as
repeat + _behaviors object (any read of an engine export, re-written) _behaviors silently ignored (rift#1709) repeat + behaviors array
{"repeat": n} element in the behaviors array (out-of-order DSL chain, repeated keys) 400 (rift#1582) effective repeat beside the response, other repeats dropped
{"copy": [..]} / {"lookup": [..]} list in an array element 400 (rift#1639) one element per item (read back the same way)

The second row reverses #217's decision to keep repeat in the array for rift 0.17.0, which has no response-level field. When the pinned engine refuses the imposter, that has to win. docs/design/sdk-api.md records the change.

0.24.0 also confines an admin-API imposter's lookup CSVs and require() to --scripts-dir, and refuses every lookup without one (rift#1611, rift#1617). SpawnOptions.scriptsDir(Path) (new) passes the flag, which the CLI has had since 0.12.0. The conformance spawn lane now uses the corpus root.

The reader now follows the same rule (rift#1709): a behaviors key, even null, or a response-level repeat voids a _behaviors object beside it. Without this, a read followed by a write would have turned on behaviors the engine had been ignoring. The legacy extra-map constructors keep both.

Closes #344
Closes #345

Verification (local, JDK 21, against the v0.24.0 release binaries)

  • RIFT_IT=1 ./mvnw verify -pl '!rift-java-testcontainers' on the spawn lane, with the v0.24.0 corpus: all green. Before the fix it failed 4 ITs (corpus 03/13, LookupGrammarIT, BehaviorRunOrderIT).
  • Embedded conformance lane: green except XPathRecordedMatchIT, which fails the same way against the 0.23.0 dylib. It's a pre-existing embedded gap from verify: align recorded(RequestMatch) XPath element value with rift 0.23 (rift#1495) #335, not caused by this bump, and will be filed separately.
  • Testcontainers module not run locally (it needs the published image); CI covers it.

Downstream

rift-scala's next rift-java bump needs a FacadeCoverage entry for SpawnOptions.scriptsDir.

🤖 Generated with Claude Code

…t admits them

rift 0.24.0 aligns behaviors with Mountebank, and three shapes this SDK wrote
are now ignored or refused:
- a _behaviors object beside a response-level repeat is ignored whole
  (rift#1709). Reading an engine export (repeat + behaviors array) and writing
  it back produced exactly that, silently dropping every behavior. The block
  is now written as the array whenever a response-level repeat is present.
- an array element holding repeat is refused (rift#1582). In the array form
  the effective repeat now goes beside the response; this reverses #217's
  choice to keep it in the array for rift 0.17.0.
- an array element holding a list of copy/lookup is refused (rift#1639). A
  list is now written, and read, one item per element.

rift 0.24.0 also confines an admin-API imposter's lookup CSVs and require()
to --scripts-dir (rift#1617), refusing every lookup without one, so
SpawnOptions gains scriptsDir and the conformance spawn lane passes the
corpus root.
….0 does

From rift 0.24.0 a behaviors key (a null one included) or a response-level
repeat voids a _behaviors object beside it whole (rift#1709), as Mountebank
already did. The reader still read that block, so writing it back as the array
0.24.0 runs would have switched on behaviors the engine had been ignoring. A
voided block is no longer read. The legacy extra-map constructors keep both,
since a caller putting them there means both.

Closes #345
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant