[amadsalmon]

Problem / Motivation

Goal: A live Transcribe dictation on a named AWS profile is not cut off because the profile's credentials refreshed mid-stream.

Amazon Transcribe ended several live dictations 40 to 138 seconds in with "The request signature we calculated does not match the signature you provided." The streaming SDK asks the credential resolver again for every audio event, and each event's signature chains from the previous one, starting at the opening request. _ProfileCredentialResolver asked the boto3 session every time, so a profile whose credentials refreshed during the stream signed the next event with a different key.

Why it matters

The stream dies part-way through and the rest of the dictation is lost. Profiles backed by credential_process or SSO refresh on their own schedule, so this can hit any session that happens to straddle a refresh.

Not a goal

• Telling the user when a stream ends early. Separate fix (Part of Dictation keeps showing Listening after Amazon Transcribe ends the stream #17842).
• The default credential chain used when no profile is set. The SDK's own resolver signs those streams and is not changed here.
• Refusing to open a stream whose credentials are already about to expire.

What changed (motivation → approach → change)

A stream should be signed with one key from start to end, so _ProfileCredentialResolver (transcribe.py) now resolves the profile's credentials once and returns the same ones on every later call. One resolver is built per live stream and per voice memo, so a new dictation still picks up fresh credentials. A live stream is capped at five minutes, and botocore refreshes credentials that have less than ten minutes left before handing them out, so the pinned credentials normally outlive the stream. The stt-streaming spec states this for the named-profile path.

Backwards compatibility

Compatible: the resolver's interface and callers are unchanged; it returns the same credentials it would have returned on the first call.

Removes nothing: no field, setting or reader goes away. A stream whose credentials were already close to expiry at open fails at expiry, where before it failed at the first refresh with a signature error.

Tests

• test_a_stream_keeps_the_credentials_it_opened_with: real botocore RefreshableCredentials inside the refresh window, where every read refreshes to new keys; the resolver keeps returning the opening keys and asks the session once.
• test_none_credentials_raises now builds the resolver through its constructor with boto3 patched, instead of __new__ plus a hand-set attribute.

prove.py: PROVEN (the new test fails with the fix reverted). The two resolver tests passed 20/20 at -n0.

Manual verification

N/A — unit coverage sufficient: the test drives botocore's real refresh logic with an injected clock, which is the exact mechanism that changes the key.

Related Issues

Part of #17842

Pattern harvest

Not generalizable: specific to an SDK that re-resolves credentials per event while chaining signatures across events.

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable)
• No secrets, credentials, or internal references in the diff

[amadsalmon]

The workflow runs for the current head are waiting for maintainer approval (fork PR, all at action_required). Could a maintainer approve them? This push removes the (#17842) docstring reference that failed the Comment History Gate on the previous head.

[amadsalmon]

Status for head 76f0b1647: every red check is an infrastructure failure, not a finding on the diff.

• Sensitive Change Review, Fork GPT 6.1 Review, Fork Opus 5.5 Review, Fork Internal Content Scan, Fork Security Scope Review: each died on API rate limit exceeded for installation between 00:44 and 00:47 UTC. Every fork review lane in the repo failed in that window.
• Dependency License Gate: Dependency review is not supported on this repository (dependency graph off). It is failing on every PR right now, same-repo ones included.

A fork author cannot rerun jobs. Once the rate limit has reset, could a maintainer run:

gh run rerun 37708507509 --failed --repo kirodotdev/KiroCrew
gh run rerun 37709518862 --failed --repo kirodotdev/KiroCrew
gh run rerun 37709517682 --failed --repo kirodotdev/KiroCrew
gh run rerun 37709517645 --failed --repo kirodotdev/KiroCrew
gh run rerun 37709517672 --failed --repo kirodotdev/KiroCrew

[github-actions]

Opus 5.5 Review (fork) — ✅ no blocking findings

Reviewed 76f0b1647ad8f5035bee595d99469a76f5f21916 via the fork AI-review pipeline; updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 76f0b16

[buluoray]

Taking this over in #19550 since it has been idle; you are credited as co-author on the commits. Thanks for the groundwork.

[amadsalmon]

Taking this over in #19550 since it has been idle; you are credited as co-author on the commits. Thanks for the groundwork.

@buluoray hi Ray, this PR is not idle. It is simply pending maintainer action.
I would like to keep full credit for the fix through both the PR and the commit.

I opened it only five days ago, but the issue is that the CI checks are so flaky and unreliable that it makes it hard to keep up with them and get them to pass to green.

I would appreciate some more support from the maintainers of this package to make it easier to pass the CI checks, without that support being taking over my PRs completely.

[iamwhatever]

Thank you, @amadsalmon. This fix is now on main: #19550 (commit 97beb72) carries "fix(stt): sign a Transcribe stream with its opening credentials" with you as co-author, and its message says it supersedes #17924. Closing this one as already merged. If anything here did not make it in, please reopen.