Parity tests: Handle multi-plugin pipeline
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
Research direction
Start in the parity suite and trace SnapshotInvocations across the Invocations.Inbound and .Outbound slices. Build the fixture with spyPluginA and spyPluginB, then verify both listeners record both invocations in the same order and expose identical SessionEvent.Plugins payloads for both custom-event keys, including the denying and observing behavior.
Written by the indexing model from the issue text.
Description
The parity suite currently runs single-plugin fixtures. Production pipelines chain several plugins (jwt-validation → parsers → litellm-budget-track etc.), and the framework's invocation-ordering, event-merging, and shadow-mode composition contracts are only exercised in per-listener tests, not across listeners.
Why it matters
SnapshotInvocationswalks the entireInvocations.Inbound/.Outboundslices — if two plugins record on the same request, order and count must match across listeners.- Two plugins emitting distinct
Extensions.Customevents under different keys must produce the sameSessionEvent.Pluginsmap on both listeners; drift here is invisible without a fixture that produces more than one key. - The dependency-ordering gate (Requires / RequiresLater) is asserted at construction, but the runtime behavior of the resulting ordering hasn't been parity-checked.
- Shadow-mode error policy composition (a plugin under
on_error: observerunning alongside an enforcing plugin) has different pctx-mutation semantics per listener; single-plugin fixtures can't reach that.
Fix
Fixture using both spyPluginA and spyPluginB with:
- Each spy emitting a distinct
Extensions.Customevent. - One spy denying at
OnRequest, the other observing; assert both listeners record both invocations in the same order. - Assert
SessionEvent.Pluginson both listeners carries both keys with identical JSON payloads.
Follow-up from #935.
- Dominant language
- Go
- Stars
- 13
- Forks
- 40
- Avg merge
- 12h 9m
- Merged PRs (30d)
- 164
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rossoctl/cortex
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
nice to have
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
stale
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Similar issues
-
needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
bug carvel-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
carvel-dev/kapp-controller#1861 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100