feat: PM-KISAN grievance in the Grievance plugin [#60] by KrutikaPhirangi · Pull Request #71 · OpenAgriNet/network-adapter

KrutikaPhirangi · 2026-10-05T11:01:04Z

What

PM-KISAN grievance in the Grievance plugin, beside PMFBY, on the Grievance pack. Application status is split out to its own PR, stacked on this one.

Action	Upstream	Mapping
`init`	`/ChatbotOTP` on the chatbot service (AES-128-CBC)	`pmkisan/grievance.init.yaml`
`support`	`/ChatbotOTPVerified`, then `/LodgeGrievance` (AES-GCM)	`pmkisan/grievance.support.yaml`
`status`	`/ChatbotOTPVerified`, then `/GrievanceStatusCheck`	`pmkisan/grievance.status.yaml`

Commits

Shared envelope (internal/common/envelope): AES-GCM and AES-CBC codecs, OTP verify before the guarded call, capability Hooks. common.Config.HostedElsewhere sends an action to another participant's host, read from the registry. ADR-0001, ADR-0002.
Schema validator: extendedSchema_contextRewrite fetches the packs from the branch until the published URL serves them; schema errors carry the reason and path, never the value. ADR-0003.
PM-KISAN grievance: mappings (no input checks; the pack has them), provider block, tests. A known refusal is a 400 naming the field, anything else a 502. ADR-0004.

Code comments are kept short; the reasoning is in the ADRs, #92.

Config

pmkisan block in config/provider-adapter.yaml. Env vars: PMKISAN_GRIEVANCE_KEY, PMKISAN_GRIEVANCE_IV, PMKISAN_SERVICE_TOKEN, PMKISAN_OTP_TOKEN. The OTP service is the pmkisan-chatbot|openagrinet:SchemeApplication binding, so that binding must be active in the registry.

Testing

Unit and mapping tests: go test ./pkg/plugin/implementation/Grievance/... ./pkg/plugin/implementation/internal/... ./pkg/plugin/implementation/schemav2validator/...
End to end against the mock PM-KISAN services in quick-start: init, support, status and the error cases.

github-actions · 2026-10-05T11:04:20Z

🛡️ Trivy security scan (CRITICAL,HIGH,MEDIUM,LOW)

View full run

Go dependencies

No findings at CRITICAL,HIGH,MEDIUM,LOW.

Container image

No findings at CRITICAL,HIGH,MEDIUM,LOW.

github-actions · 2026-10-05T11:06:40Z

📊 Test Coverage: ✅ Passed — 87% of changed lines covered, min 80%

- The OTP verify and the follow-up read share one client that refuses an off-host redirect, as common's does, so a 302 cannot re-POST the farmer's identifier to another host. - Envelope settings without envelope: are refused at startup instead of sending the body unsealed. - The verify and the follow-up run on their own budgets, otpVerifyTimeoutMs and followUpTimeoutMs (default 15000), not the action's, so one status no longer spends three of its timeouts. - The GCM comment says what a fixed nonce breaks, and a nonce shorter than 12 bytes is refused.

…s binding [#60] Answers the remaining review on PR #71. The envelope -- AES-GCM and AES-CBC codecs, the challenge verify, the follow-up read -- moves from Grievance to internal/common/envelope. None of it is grievance knowledge, so the next provider with an encrypted upstream uses it without importing a package called Grievance. What a capability does know comes in as Hooks: where its payload carries the challenge, and what its provider's "yes" looks like. Grievance keeps only those (otp.go) and calls envelope.Parse. The OTP service is no longer an env var. otpBindingKey names the binding whose participant serves it (pmkisan-chatbot|openagrinet:SchemeApplication), and its host is read from the registry per call, with the same status checks as any participant, so the address lives in one place. common.Config.HostedElsewhere sends an action to that participant's host; it replaces the Router interface and BaseURLFor, which existed only for this redirect. An unpublished OTP binding is a 502.

manjudr · 2026-10-23T07:39:20Z

@KrutikaPhirangi - The PR is too big—Can you split the application status and grievance ?

…on on another participant [#60] internal/common/envelope seals a mapped request and opens the answer: aesGcm (fixed key and nonce) and aesCbcKeyInBand (fresh key per request), with the service token added after the mapping. It can verify a challenge on the provider before the guarded call, on its own budget, through a client that refuses an off-host redirect. A capability supplies Hooks: where its payload carries the challenge and what its provider's "yes" looks like. common.Config.HostedElsewhere sends an action to the participant behind another binding key, its host read from the registry per call (common.HostOf).

@context

…ue out of the rest [#60] extendedSchema_contextRewrite takes "from|to" prefix pairs: a pack whose published @context does not serve it is fetched from the rewritten URL, while the payload keeps its @context. The allowlist is checked on the rewritten host. Schema errors already carry the reason alone; a non-schema error and the two debug logs that printed the raw error now drop the schema and the offending value too, which a pack can mark no-echo.

PM-KISAN grievance on the Grievance pack: init sends an OTP through the chatbot service's participant (otpBindingKey), support lodges and status reads, each after the OTP is verified there. Bodies are AES-GCM with the service token inside. The mappings only build bodies and read answers; input rules are the pack's. A refusal with a known reason (an unknown registration number) is a 400 BIZ_GENERIC_ERROR naming the field; any other is a 502; no record found is a 400. The provider's text is logged, never returned.

KrutikaPhirangi force-pushed the feat/60-pmkisan-grievance branch 5 times, most recently from 7b9405d to c52852f Compare October 12, 2026 07:11

KrutikaPhirangi changed the title ~~feat: serve PM-KISAN grievances from the Grievance plugin [#60]~~ feat: PM-KISAN grievance and application status in the Grievance plugin [#60] Oct 12, 2026

KrutikaPhirangi requested a review from ameersohel45 October 12, 2026 07:24