Skip to content

fix: preserve envelope extensions in flow input#110

Open
BimaPangestu28 wants to merge 7 commits into
mainfrom
fix/preserve-envelope-extensions-in-flow-input
Open

fix: preserve envelope extensions in flow input#110
BimaPangestu28 wants to merge 7 commits into
mainfrom
fix/preserve-envelope-extensions-in-flow-input

Conversation

@BimaPangestu28
Copy link
Copy Markdown
Member

Summary

  • Promote metadata.extensions JSON string into typed envelope.extensions at ingress
  • Pin extensions.channel_data JSON Pointer reaching flow input
  • Add webchat gateway hardening proposal and implementation plan
  • Bump version to 0.5.7

Test plan

  • cargo test passes
  • CI green

vampik33 and others added 7 commits April 26, 2026 21:45
Enrolls greentic-start in nightly dev-publish pipeline.
Publishes greentic-start to AWS CodeArtifact on push to develop.
Plan B companion to the greentic-designer AI Assistant template (PR #82).
Scopes per-IP rate limit on /v1/messaging/webchat/{tenant}/token + tenant
allowlist validation for public embed safety. ~3-4 dev days, independent
subsystem.

Awaiting Maarten review on 5 open questions (default allowlist mode, XFF
trust default, burst size, LRU cap, admin metrics integration) before
execution.
TDD task breakdown across 6 tracks (~12 tasks):
- G1: GatewayGuardConfig env parser + allowlist logic
- G2: governor-based per-IP token rate limiter + guard for /token
- G3: tenant allowlist guard with opaque 404
- G4: wire guards into hyper handle_request + XFF-aware IP resolution
- G5: hyper loopback integration tests (429 + 404 + happy path)
- G6: docs + PR

Est. ~3-4 dev days single developer. Deferred execution until
Maarten reviews the companion proposal's 5 open questions.
…g flow input

Add regression guard that asserts ChannelMessageEnvelope.extensions["channel_data"]
survives the json!({"input": envelope, ...}) shape that run_app_flow builds
for the runner. Pins both:

- canonical JSON Pointer /input/extensions/channel_data/r1_principals
- snake_case key naming (channelData camelCase must NOT match)

Investigation found the path from HTTP ingress (route_messaging_envelopes)
through messaging_app::run_app_flow, runner_exec::run_provider_pack_flow,
greentic-runner-desktop::run_pack_async, into FlowEngine::execute /
ExecutionState::new is clean — no field whitelist drops envelope extensions.
The R1 demo's null r1_principals is therefore downstream (flow node mapping
not forwarding the extension, or WASM reading the wrong key).

No production code changes: greentic-start is already correct as of 0.5.4.
…lope.extensions

WASM messaging providers compiled against `greentic-types` 0.4.x
(via the v0.4.84 'neutral presentation' refactor) emit
`metadata["extensions"]` as a JSON-encoded string rather than the
typed `ChannelMessageEnvelope.extensions` field that
`greentic-types` 0.5.x exposes. As a result the typed field arrived
empty at greentic-start and the runner never saw DirectLine
`channel_data` / `attachments` / `entities` — TASK-082 Bug 3
regression that surfaced as `r1_principals` dropping on the wire.

`parse_messaging_envelopes` now parses the metadata string back into
an object and inserts each key into `envelope.extensions` with
`Entry::or_insert` semantics, so already-typed envelopes win and
stringified envelopes are upgraded once before they reach the runner.

Pinned by two new tests:
- promotes_metadata_extensions_string (regression for the WASM-side
  shape produced by the published webchat-gui:latest image)
- keeps_existing_typed_extensions (precedence guarantee for providers
  that already populate the typed field)
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.

2 participants