EPCIS no-filter events query returns EPCISDocument container rows

[zsculac]

This was generated by AI during triage.

Summary

No-filter EPCIS event queries can return the EPCISDocument container as if it were an event.

Repro

On a live rc.11 testnet node:

1. Capture a valid EPCIS document containing one ObjectEvent.
2. Query without an event filter:

dkg epcis query --context-graph-id <cg> --finalized false --per-page 10

3. Query with an explicit event type:

dkg epcis query --context-graph-id <cg> --finalized false --event-type ObjectEvent

Actual

The no-filter query returned two entries:

ObjectEvent
EPCISDocument

The explicit eventType=ObjectEvent query returned one event.

The extra row is sparse, for example:

{ "type": "EPCISDocument" }

Likely root cause: packages/epcis/src/query-builder.ts matches every RDF type under the EPCIS namespace:

FILTER(STRSTARTS(STR(?eventType), "https://gs1.github.io/EPCIS/"))

That includes https://gs1.github.io/EPCIS/EPCISDocument, not just EPCIS event classes.

Expected

/api/epcis/events should return EPCIS events only. Container/document resources should be excluded from event result sets unless a separate endpoint intentionally exposes documents.

Evidence

Probe artifact:

/var/folders/bj/nmx4wm3j6c9g5dxr27xmm2dm0000gn/T/dkg-rc11-deep-pass/adv-mpn0d9gp.json

Digest:

a4b3f8008f5e2a7f9e7d458d5cd36ed77b16348f6d0538888aa1104827d47293

Local probe script:

devnet/rc11-deep-pass/live-testnet-adversarial-probes.mjs

[Bojan131]

Automated liveness test added in PR #1129 (docs/testing/ISSUE_LIVENESS_TESTS.md). The test asserts the correct behaviour and currently fails-as-expected (bug confirmed live on main as of 2026-06-11). When this is fixed the test flips RED — remove its it.fails wrapper and close this issue.