release: corte de agosto — develop para main (12 commits) - #10
Merged
Conversation
The bot-runtime made a single call to the AI Processor: any non-200 (401/5xx) or network error aborted the pipeline and the customer's message was dropped with no reply and no retry (only AI_CALL_TIMEOUT_SECONDS existed). A momentary blip — deploy, restart, DB hiccup — meant a permanently lost answer. - ai_adapter.go: extract a single attempt into doOnce() and wrap Call() in a retry loop with exponential backoff + jitter. Retryable: network errors and 429/500/502/503/504. NOT retried: 4xx (permanent), per-attempt timeout, pipeline cancellation. Body is built once and reused per attempt. - config.go: AI_CALL_MAX_RETRIES (default 2) and AI_CALL_RETRY_BASE_MS (default 200). - main.go: wire the new config into NewAIAdapter. - tests: 503->200 retry succeeds (2 calls); persistent 500 exhausts retries (1+2 calls); 400 not retried (1 call); network error then success (2 calls); maxRetries=0 disables retry. Existing tests updated to the new signature (0 retries). Complements EVO-2166: the processor now returns 503 (not a silent 401) on infra errors, so this retry covers the transient auth/infra case. Root cause of the incident is EVO-2141 (pool_pre_ping, already merged); this is defense in depth. Note: test/e2e/e2e_test.go was already incompatible with NewAIAdapter on develop (pre-existing, unrelated) and is left as-is; repo CI is docker-only (no go test lane).
Review follow-ups on the AI Processor retry path: - Add an overall time-budget backstop so the retry loop is provably bounded ((attempts+1) x per-attempt timeout + summed max backoff); the +1 slack keeps a per-attempt timeout surfacing as ErrAITimeout instead of being swallowed by the backstop. AC "teto de tempo total". - Add TestCall_TimeoutIsNotRetried: a per-attempt timeout must return ErrAITimeout and must NOT be retried with retries enabled. AC #5 "timeout por tentativa". - Document the idempotency contract on the retry path (502/504/network replay can re-run an already-processed turn; customer still gets one reply; dedupe of the duplicate server-side turn is the AI Processor's job, tracked in EVO-2166).
…ssor-retry fix(EVO-2167): retry the AI Processor call on transient failures
…e parts
The bot only ever sent a text part, so images/audio the customer sent never
reached the AI (the agent replied "No content to process"). Accept attachments on
the inbound event, carry them through the debounce window, download each and send
it as a base64 A2A file part. Part of EVO-2178 (image end-to-end).
- pipeline/model: MessageEvent.Attachments + Attachment{URL,ContentType,FileType}.
- pipeline/repository: AppendAttachments/GetAttachments on a parallel Redis list
(bot_runtime:attach:{contact}:{conv}), aggregated like the text buffer and cleared
together in ClearState (no stale media leaks into the next turn).
- debounce/service: Start/Reset accept attachments; GetAttachments added.
- pipeline/service: thread event.Attachments through start/skip/reset/advance -> the
A2ARequest (read fresh from Redis at stage launch, like the buffer).
- ai/model: A2ARequest.Attachments; JSONRPCPart.File + JSONRPCFile{Name,MimeType,Bytes}
(tags match the processor's extract_files_from_message).
- ai/service/ai_adapter: download each attachment once (before Marshal, reused across
retries) with a 15 MiB cap; base64-encode; append a file part. A download failure is
logged and skipped so the text-only message always survives.
- tests: adapter forwards a file part with decodable base64 + download-failure sends
text only; repo AppendAttachments/GetAttachments roundtrip + ClearState clears the
attach key. Full suite green (go build/vet/test ./pkg/... ./internal/...).
Note: test/e2e was already incompatible with NewAIAdapter on develop (pre-existing);
repo CI is docker-only.
Review follow-ups on the incoming-media path. The per-file cap was the only bound, so the failure modes it did not cover fell back on the customer losing the whole reply instead of just the media. - Shared byte budget (20 MiB) across every attachment of the call. The debounce window aggregates the media of all its messages, so a photo burst built a body of len(attachments) x 15 MiB; base64 pushed that past the gateway's client_max_body_size and the resulting 413 is not retryable, killing the text reply too. Probe: 20 x 2 MiB went from a 53 MiB request to 26 MiB. - Dedicated download timeouts. Downloads run before the AI call and outside its retry ceiling, but reused AI_CALL_TIMEOUT_SECONDS (30s) per attachment, so an unreachable media host stalled the turn by 30s x len(attachments) with no bound. Now 10s per download and 30s for the whole set. - Resolve the mime type from the bytes in hand: the response Content-Type wins, then the CRM's declared type, then the URL extension. The processor feeds this straight into Blob(mime_type=...), so an HTML error/login page answered with 200 was being forwarded as a valid image, and a missing content_type became application/octet-stream. Both are now dropped or resolved. - A Redis failure on the attachment buffer no longer aborts the turn: media is best-effort everywhere else in this path, and dropping the text reply over it contradicted the card's own acceptance criterion. Tests: the event -> debounce -> Redis -> A2ARequest seam had no coverage (the debounce mock always returned nil attachments), so a refactor could silently drop the media; two pipeline tests now pin it, including aggregation across the debounce window. Adapter tests cover the byte budget, the time budget, HTML responses, oversize files and the mime resolution table. Also repairs test/e2e, which has not compiled since EVO-2167 changed NewAIAdapter/NewDispatchEngine — which is why `go vet ./...` and `go test ./...` could not be run at all. Two assertions had drifted: the message signature moved to a prefix on the first segment in EVO-558, and the state-leak check raced the cleanup goroutine it was asserting on. go build ./... && go vet ./... && go test ./... green, e2e included.
…inbound-media feat(EVO-2180): forward incoming media to the AI Processor as A2A file parts
Review follow-up to EVO-2180. Attachment URLs arrive inside the /events payload and the adapter fetched them verbatim, so the endpoint doubled as a read primitive aimed by its caller: the bytes of any URL reachable from this service were base64-encoded into the A2A call, whose destination (outgoing_url) comes from the same payload. Reproduced end to end against a local metadata-style endpoint, both directly and through a 302. - checkMediaURL pins the scheme to http/https and requires the host to be one the CRM is known to serve blobs from: the postback URL's host (already mandatory in MessageEvent.Validate, so no new config for the default topology) plus whatever MEDIA_HOST_ALLOWLIST names, for deployments serving blobs off an S3/MinIO/CDN host. Unauthorized media is skipped and logged; the text reply is unaffected, like every other media failure here. - The download client re-runs that check on every redirect hop, so an authorized host cannot walk the fetch onto an internal address. - BOT_RUNTIME_SECRET becomes required. It was read with os.Getenv, and SecretMiddleware compares the header against it, so an empty value authenticated every caller that simply omitted the header. - The media buffer key gets a TTL. ClearState remains the normal cleanup; the TTL only stops a turn that dies before reaching it from leaving media URLs in Redis forever. - Attachment download failures now log the HTTP status: the common production case is a 404 from a signed link that expired while the queue was backed up, and it read identically to an unreachable host. - Adds .github/workflows/ci.yml. Nothing ran the Go suite on a PR, which is how test/e2e stayed non-compiling from EVO-558 until EVO-2180.
…srf-guard fix(EVO-2178): validate incoming media URLs before fetching them
…e event Fixes a regression I introduced in #6. The allowlist was anchored on the host of the event's postback_url, which never matches the host the CRM actually signs media URLs with: postback_url comes from BOT_RUNTIME_POSTBACK_BASE_URL (internal DNS, "evo-crm" in the shipped compose) while the URL is built from ACTIVE_STORAGE_URL, falling back to BACKEND_URL — which production requires to be a public host. So on develop every attachment was rejected as blocked_url and the agent stopped seeing images: the EVO-2178 bug, back. Anchoring on the event was also the wrong shape for the guard. Whoever sends the event chooses every field in it, including the one being used to decide what that same event may reach, so the check constrained nobody it needed to. Reading MEDIA_HOST_ALLOWLIST only puts the decision with the operator, where it cannot be chosen by the caller. A2ARequest.PostbackURL is dropped again. The scheme check and the per-redirect re-check are unchanged. This makes the variable required wherever media is expected: unset means no attachment is fetched. The deploy surfaces are wired up in the umbrella PR; k8s/configmap.yaml and k8s/deployment.yaml carry it here.
…lowlist-from-config fix(EVO-2178): take the media host allowlist from config, not from the event
…provider-feedback fix(pipeline): tell the customer when the AI backend fails (CRM-236)
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @gomessguii, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 15 hours and 3 minutes by commenting @sourcery-ai review. Upgrade to get a review now.
Reviewer's GuideThis release promotes develop to main while introducing CI, stricter runtime configuration, resilient AI Processor retries and failure notices, and complete best-effort media forwarding through the debounced pipeline with SSRF, size, MIME, and time safeguards. Sequence diagram for debounced media forwarding and AI retrysequenceDiagram
participant CRM as CRM
participant Pipeline as PipelineService
participant Redis as Redis
participant Adapter as AIAdapter
participant Media as MediaHost
participant AI as AIProcessor
participant Dispatch as DispatchEngine
CRM->>Pipeline: Process(MessageEvent)
Pipeline->>Redis: AppendAttachments
Pipeline->>Redis: GetAttachments
Pipeline->>Adapter: Call(A2ARequest with Attachments)
loop Each authorized attachment
Adapter->>Media: HTTP GET attachment URL
Media-->>Adapter: Media bytes and Content-Type
end
loop Transient failure and retries remain
Adapter->>AI: HTTP POST JSON-RPC with text and file parts
AI-->>Adapter: 429, 5xx, or network error
Adapter->>Adapter: backoffDelay
end
Adapter->>AI: HTTP POST JSON-RPC
AI-->>Adapter: Successful response
Adapter-->>Pipeline: NormalizedResponse
Pipeline->>Dispatch: Dispatch
Dispatch-->>CRM: Agent reply
Flow diagram for AI failure notificationflowchart TD
A[AIAdapter.Call] --> B{AI call succeeds?}
B -->|Yes| C[Dispatch]
B -->|No| D[clearStateWithLog]
D --> E{AI_FAILURE_NOTICE configured?}
E -->|Disabled| F[End]
E -->|Enabled or default| G[sendAIFailureNotice]
G --> H{postback URL available?}
H -->|No| F
H -->|Yes| I[Dispatch]
I --> F
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Corte de release: leva a
developpara amain— 12 commits, 4 cards.Faz parte da cascata que leva o evolution-ecosystem para produção, parada em 2 de julho. A
maindo superprojeto aponta para SHAs que estão namainde cada submódulo, então cada repositório corta primeiro; o superprojeto bumpa os ponteiros por último.Merge testado com
git merge-treeantes de abrir: sem conflitos.Este repositório não depende dos demais dentro da cascata — pode ser mergeado em qualquer ordem em relação aos irmãos.
As migrations do conjunto foram ensaiadas contra uma cópia restaurada do banco de produção (Postgres 18.6, imagens por digest): cinco passos do
migrate-job, todos exit 0, dado intacto, idempotência confirmada.Runbook: https://claude.ai/code/artifact/3a9608d8-4126-4c9c-9934-8e0e9074fbff
Summary by Sourcery
Improve pipeline resilience and multimodal message handling while adding automated validation and safer production defaults.
New Features:
Bug Fixes:
Enhancements:
CI:
Deployment:
Tests: