- Shipped
- September 7, 2026 at 6:42 AM UTC
- Author
- Kamo
- Commit
- c86c4ea
Approving a submission now tells SecurityService to recount that member's SPREAD_THE_WORD standing, so the trophy lands in the same second as the decision rather than on the member's next page load. `GrowthAchievementClient` mirrors `MemberNotificationClient`: this service owns the Growth Hub, SecurityService owns the achievement spine, and the producer asks the owner rather than writing into it. It sends WHO, never how many — the other end recounts the approved rows itself, so nothing here can overstate a member's standing. Two things about it are load-bearing. It fires from afterCommit. The recount runs in SecurityService's own transaction against the same database, so a call made from inside the approving transaction would count the rows as they were BEFORE the approval, settle the member one mission short, and answer 200 — there would be no failure to find afterwards. `GrowthAchievementClientTest` overrides the POST to pin exactly that ordering, and pins that a rolled-back approval tells nobody anything. And it stamps **************** NOT internal.auth.secret. Two cluster secrets exist and they hold different values: SecurityService validates the public-chat one (both services mount that Secret), while this service wires internal.auth.secret to INTERNAL_AUTH_SECRET from mlos-internal-auth, which is what the notification client sends to EmailService. Stamping that one here 403s every call, and does it silently — the response is discarded on purpose. Best effort throughout: a failure here costs the instant popup and nothing more, because every achievements read recounts from the same rows.