Fix binary response inference for empty media types#151
Merged
github-actions[bot] merged 1 commit intomainfrom Mar 13, 2026
Merged
Fix binary response inference for empty media types#151github-actions[bot] merged 1 commit intomainfrom
github-actions[bot] merged 1 commit intomainfrom
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
WalkthroughThis PR enhances binary response handling by introducing a new MIME type detection extension and updating response processing logic. Generated API methods for binary content now return Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (12)
src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs (1)
168-180:⚠️ Potential issue | 🟠 MajorMissing
ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContentcall in theelsebranch.The partial method hook is invoked in the
if (ReadResponseAsString)branch (lines 143-146) but is absent in thiselsebranch. This asymmetry means consumers implementing the partial method won't have their hook called whenReadResponseAsStringisfalse.🐛 Proposed fix to add the missing partial method call
var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs around lines 168 - 180, The else branch after reading the byte[] (__content) is missing a call to the partial hook ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContent, causing consumers to miss the hook when ReadResponseAsString is false; update the else branch in the GetPronunciationDictionariesByDictionaryIdByVersionIdDownload response handling to invoke ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContent(__response, __content, __headers) (matching the call made in the ReadResponseAsString branch) before returning __content so the partial method is always executed regardless of ReadResponseAsString.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs (1)
168-195:⚠️ Potential issue | 🟡 MinorMissing
ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContenthook call in the else branch.The
ReadResponseAsString=truebranch (lines 143-146) callsProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent, but theelsebranch does not. This creates inconsistent behavior where implementers of the partial method would have their hook invoked only whenReadResponseAsStringis true.For consistent behavior, the hook should be called in both branches before returning:
🔧 Proposed fix
try { __response.EnsureSuccessStatusCode(); var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs around lines 168 - 195, The else branch that returns the byte[] response misses calling the partial hook ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent, causing inconsistent behavior vs the ReadResponseAsString branch; to fix, invoke ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent in the else branch after reading __content and before returning, passing the same parameters used in the ReadResponseAsString branch (the response, the response content representation used there, and any headers/status info) so implementers get the hook in both code paths.src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cs (1)
99-102:⚠️ Potential issue | 🟡 MinorUnused stream read in 302 error handling.
__contentStream_302is assigned but never used, resulting in unnecessary I/O. If the stream content isn't needed for the exception, consider removing this branch or using the stream data.Suggested fix
else { - var __contentStream_302 = await __response.Content.ReadAsStreamAsync(cancellationToken).ConfigureAwait(false); + // Stream content not needed for redirect handling }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs around lines 99 - 102, The else branch currently reads the response stream into the unused local __contentStream_302 causing unnecessary I/O; either remove that branch entirely or consume/dispose the stream content appropriately: locate the 302 error handling block where __contentStream_302 is assigned (the else branch after the 302 response check) and either delete the await __response.Content.ReadAsStreamAsync(...) call or replace it with code that reads/disposes the stream (e.g., copy to a buffer, call ReadAsStringAsync, or use a using/Dispose) so the stream is not leaked and no unused variable remains.src/tests/AutoSDK.SnapshotTests/Snapshots/CLI/ultravox/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cs (1)
99-102:⚠️ Potential issue | 🟡 MinorUnused stream read in 302 error handling.
Same issue as in the NewtonsoftJson variant:
__contentStream_302is read but never used.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/CLI/ultravox/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs around lines 99 - 102, The else block in the CallsRecordingRetrieve test reads a response stream into __contentStream_302 but never uses it; remove the unused ReadAsStreamAsync call or wrap it in a using/dispose if you intend to consume it (e.g., for logging). Locate the else branch that declares __contentStream_302 in the CallsRecordingRetrieve-generated snapshot test and either delete the await __response.Content.ReadAsStreamAsync(...) assignment or change it to a properly disposed/used stream (or read to a string for logging) so the variable is not allocated and leaked unused.src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/SystemTextJson/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cs (1)
155-167:⚠️ Potential issue | 🟠 MajorInvoke response-content hook in both byte[] paths.
ProcessCallsRecordingRetrieveResponseContentis skipped whenReadResponseAsStringisfalse(Line 161 onward). Since both branches now readbyte[], this creates inconsistent behavior based on an unrelated flag.Proposed fix
else { try { __response.EnsureSuccessStatusCode(); var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessCallsRecordingRetrieveResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/SystemTextJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs around lines 155 - 167, The response-content hook ProcessCallsRecordingRetrieveResponseContent must be invoked regardless of ReadResponseAsString; update the code paths in the method handling CallsClient.CallsRecordingRetrieve (the branch that reads byte[] into __content and the other byte[] branch) to call ProcessCallsRecordingRetrieveResponseContent(__response, __content) before returning, ensuring the hook runs for both byte[] flows and not only when ReadResponseAsString is true; locate the usages around __response.EnsureSuccessStatusCode(), the __content variable assignments, and the early return statements and insert the hook invocation in both byte[] return paths.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs (2)
245-259:⚠️ Potential issue | 🟡 MinorAdd explicit null checks for non-nullable wrapper parameters.
audioandaudionameare non-nullable, but there are no guard clauses before building the request object. Add explicit checks to match project standards and fail fast.As per coding guidelines "Validate parameters with explicit null checks in C# code".Proposed fix
public async global::System.Threading.Tasks.Task<byte[]> CreateAudioIsolationAsync( byte[] audio, string audioname, string? xiApiKey = default, global::G.BodyAudioIsolationV1AudioIsolationPostFileFormat2? fileFormat = default, string? previewB64 = default, global::System.Threading.CancellationToken cancellationToken = default) { + audio = audio ?? throw new global::System.ArgumentNullException(nameof(audio)); + audioname = audioname ?? throw new global::System.ArgumentNullException(nameof(audioname)); + var __request = new global::G.BodyAudioIsolationV1AudioIsolationPost { Audio = audio, Audioname = audioname, FileFormat = fileFormat, PreviewB64 = previewB64, };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs around lines 245 - 259, The CreateAudioIsolationAsync method builds a request from parameters that are declared non-nullable (audio and audioname) but lacks guard clauses; add explicit null checks at the start of CreateAudioIsolationAsync to throw ArgumentNullException for audio and audioname (use nameof(audio)/nameof(audioname)) before constructing the global::G.BodyAudioIsolationV1AudioIsolationPost request so the method fails fast and follows the project's parameter validation guidelines.
193-206:⚠️ Potential issue | 🟠 MajorInvoke response-content hook in the non-string branch too.
Line 205 returns raw bytes without calling
ProcessCreateAudioIsolationResponseContent, so behavior differs based onReadResponseAsString. That can skip custom binary post-processing unexpectedly.Proposed fix
else { try { __response.EnsureSuccessStatusCode(); var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessCreateAudioIsolationResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content; } catch (global::System.Exception __ex) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs around lines 193 - 206, The non-string branch currently returns raw bytes after EnsureSuccessStatusCode without invoking the response-content hook; call ProcessCreateAudioIsolationResponseContent (passing __response and the byte[] __content) and use its returned/possibly-processed bytes before returning, mirroring the string branch behavior; update the path around EnsureSuccessStatusCode in the CreateAudioIsolation method to invoke ProcessCreateAudioIsolationResponseContent with __response and __content and return that value instead of the raw __content.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs (1)
237-250:⚠️ Potential issue | 🟠 MajorInvoke
ProcessCreateMusicStemSeparationResponseContentin the non-string path too.Line 243-249 returns bytes without running the response-content partial hook, unlike Line 212-215. This makes behavior depend on
ReadResponseAsStringand can silently bypass custom post-processing.Proposed fix
try { __response.EnsureSuccessStatusCode(); var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessCreateMusicStemSeparationResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs around lines 237 - 250, The non-string response path returns raw bytes without invoking the post-processing hook; call ProcessCreateMusicStemSeparationResponseContent before returning bytes in the else branch. Specifically, after __response.EnsureSuccessStatusCode() and after reading __content via __response.Content.ReadAsByteArrayAsync, invoke ProcessCreateMusicStemSeparationResponseContent(__response, __content, ReadResponseAsString) (or the overload used elsewhere) to run the partial hook, then return the (possibly modified) byte[] result; mirror how the string path around ProcessCreateMusicStemSeparationResponseContent is used to ensure consistent behavior.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.MusicGenerationClient.CreateMusicStream.g.verified.cs (2)
154-157:⚠️ Potential issue | 🟠 MajorKeep the byte[] content hook on both success paths.
ProcessCreateMusicStreamResponseContentonly runs whenReadResponseAsStringistrue. With the current split, consumers lose their partial post-processing as soon as that flag isfalse, even though both branches now return the samebyte[]payload.💡 Minimal fix
var __content = await __response.Content.ReadAsByteArrayAsync( `#if` NET5_0_OR_GREATER cancellationToken `#endif` ).ConfigureAwait(false); + ProcessCreateMusicStreamResponseContent( + httpClient: HttpClient, + httpResponseMessage: __response, + content: ref __content); + return __content;Also applies to: 181-191
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.MusicGenerationClient.CreateMusicStream.g.verified.cs around lines 154 - 157, The response post-processing hook ProcessCreateMusicStreamResponseContent is only invoked when ReadResponseAsString is true, causing consumers to miss the byte[] content hook on the alternate success path; update the CreateMusicStream response handling so that ProcessCreateMusicStreamResponseContent(httpClient: HttpClient, httpResponseMessage: __response, content: ref __content) is called in both success branches (the ReadResponseAsString true branch and the byte[] return branch) before returning, ensuring both paths invoke the same post-processing; do the same change for the other occurrence mentioned (the block around lines 181-191) so both success paths consistently call the hook.
167-176:⚠️ Potential issue | 🟠 MajorDon't drop the buffered error payload here.
At this point
__contenthas already been read, but the newApiExceptiononly keepsReasonPhrase. For unmodeled 4xx/5xx responses that still return JSON/text, that throws away the server's actual diagnostic message.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.MusicGenerationClient.CreateMusicStream.g.verified.cs around lines 167 - 176, The generated exception drops the buffered response body (__content) and only uses __response.ReasonPhrase; update the ApiException construction in CreateMusicStream (where __response, __ex and __content are in scope) to preserve the response payload by including __content: either append it to the message passed to new global::G.ApiException or assign it to a response-body property on the exception instance (e.g., set a ResponseBody/Content property on the returned ApiException) and keep ResponseHeaders as-is so unmodeled 4xx/5xx JSON/text payloads are retained for diagnostics.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs (1)
245-264:⚠️ Potential issue | 🟠 MajorFail fast on null
audioandaudionamein the convenience overload.From nullable-oblivious callers,
audio = nullcurrently turns intoArray.Empty<byte>()andaudioname = nullinto an empty multipart filename later in this generated path, so invalid input gets serialized instead of rejected. Add explicit guards before constructing__request.As per coding guidelines, "Validate parameters with explicit null checks in C# code."🛡️ Proposed fix
public async global::System.Threading.Tasks.Task<byte[]> CreateAudioIsolationAsync( byte[] audio, string audioname, string? xiApiKey = default, global::G.BodyAudioIsolationV1AudioIsolationPostFileFormat2? fileFormat = default, string? previewB64 = default, global::System.Threading.CancellationToken cancellationToken = default) { + audio = audio ?? throw new global::System.ArgumentNullException(nameof(audio)); + audioname = audioname ?? throw new global::System.ArgumentNullException(nameof(audioname)); + var __request = new global::G.BodyAudioIsolationV1AudioIsolationPost { Audio = audio, Audioname = audioname, FileFormat = fileFormat,🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs around lines 245 - 264, In the CreateAudioIsolationAsync convenience overload, add explicit null checks for the audio and audioname parameters before constructing __request: if audio is null throw new ArgumentNullException(nameof(audio)) and if audioname is null throw new ArgumentNullException(nameof(audioname)). Update the method (CreateAudioIsolationAsync that builds the global::G.BodyAudioIsolationV1AudioIsolationPost __request) to perform these guards so invalid input is rejected rather than being converted to empty values downstream.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.AgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cs (1)
127-172:⚠️ Potential issue | 🟠 MajorInvoke the byte[] response hook in both runtime modes.
ProcessGetConvaiConversationsByConversationIdAudioResponseContentonly runs in theReadResponseAsStringbranch, and there it runs beforeEnsureSuccessStatusCode(). WithReadResponseAsString == false, custom partial implementations never see successful responses; withtrue, they also see failed ones. Please move the hook behind the success check and execute it for both paths, or collapse the duplicated branches into a single byte[] success path.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.AgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cs around lines 127 - 172, The response processing hook ProcessGetConvaiConversationsByConversationIdAudioResponseContent is only invoked in the ReadResponseAsString branch and before EnsureSuccessStatusCode(), so custom partials see failed responses in one path and no successful responses in the other; fix this by collapsing the two byte[] paths into a single success path: call __response.EnsureSuccessStatusCode() first, then read the bytes via __response.Content.ReadAsByteArrayAsync(...) into __content, then invoke ProcessGetConvaiConversationsByConversationIdAudioResponseContent(httpClient: HttpClient, httpResponseMessage: __response, content: ref __content), and finally return __content (preserving the ReadResponseAsString conditional only if other behavior depends on it).
🧹 Nitpick comments (7)
src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs (1)
135-141: Consider renaming or documentingReadResponseAsStringusage for binary endpoints.The
ReadResponseAsStringflag name is now semantically misleading since both branches callReadAsByteArrayAsyncfor binary responses. This is likely a generator-level concern rather than something to fix in this snapshot, but worth noting for clarity in the generated code.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs around lines 135 - 141, The flag ReadResponseAsString is misleading for binary endpoints because both branches call ReadAsByteArrayAsync; update the generator or surrounding code to either rename the flag to something like ReadResponseAsBytes/ReadResponseAsBinary or add an inline comment/documentation next to the ReadResponseAsString usage in the generated method (the conditional block that reads __response.Content.ReadAsByteArrayAsync) clarifying that this flag controls response reading behavior for binary payloads and that both true/false branches will use byte-array reads for this endpoint; ensure references to ReadResponseAsString in the method and any generation templates (the conditional around ReadAsByteArrayAsync) are updated consistently.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs (1)
135-167: Minor naming inconsistency:ReadResponseAsStringnow reads bytes.The condition
if (ReadResponseAsString)at line 135 is semantically misleading since the code now reads the response as a byte array viaReadAsByteArrayAsync. This is likely an artifact of the code generation template that originally handled string responses.If this is generated code, consider updating the generator's template or the flag name (e.g.,
ReadResponseBufferedorBufferResponseContent) to better reflect its actual behavior for binary content scenarios.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs around lines 135 - 167, The flag ReadResponseAsString is misleading because the code path reads a byte array; update usages and the flag name to reflect buffered/binary handling (e.g., rename ReadResponseAsString to ReadResponseBuffered or BufferResponseContent) and adjust all references in the same generated client code path (including the conditional around ReadResponseAsString and any related logic in ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent and response-returning methods) so the boolean name matches behavior, or change the condition to a properly named flag in the generator template so generated methods consistently use the new name.src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cs (1)
141-153: Consider: Error diagnostics may lose response body information.When an exception occurs,
ResponseBodyis no longer populated since content is nowbyte[]. This is understandable for binary responses, but if the server returns an error with a text body, that diagnostic information is lost. This may be acceptable for binary endpoints, but worth noting for the generator logic.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs around lines 141 - 153, The catch block that throws G.ApiException currently only sets ResponseHeaders and loses response body content because content is a byte[]; update the catch in the same method that builds the ApiException (the catch handling __ex and constructing new global::G.ApiException) to attempt to read __response.Content as a byte[] and then: if the bytes decode as UTF-8 (or other expected text encoding) set the exception's ResponseBody to the decoded string, otherwise set ResponseBody to a safe representation (e.g., base64 or null) so binary payloads are preserved; ensure you use the existing __response.Content and set the ResponseBody property on the created global::G.ApiException before throwing.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs (1)
223-227: Consider preserving response-body context in non-422 error exceptions.Line 226 now uses only
ReasonPhrasefor message text. For non-422 failures, this drops useful server diagnostics that were previously easier to surface.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs around lines 223 - 227, The current catch in CreateMusicStemSeparation throws G.ApiException using only __response.ReasonPhrase, which loses server diagnostics; update the throw to include the response body content when available (e.g., read __response.Content.ReadAsStringAsync() and append or interpolate it into the message for non-422 errors) while preserving the existing innerException (__ex) and other exception fields so the full response context is surfaced in G.ApiException.src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs (1)
154-166: Error handling omits response body for binary content.The
ApiExceptionthrown here no longer setsResponseBody, which differs from the 422 error handling (lines 121-132). This is likely intentional since binary data can't be meaningfully displayed as a string message, but verify this is the expected behavior for debugging/logging purposes.Consider whether it would be useful to include a hex dump or length indicator of the byte content in error scenarios for debugging purposes, or document why
ResponseBodyis intentionally omitted for binary responses.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs around lines 154 - 166, The catch block that throws new global::G.ApiException in GetPronunciationDictionariesByDictionaryIdByVersionIdDownload currently omits ResponseBody for binary responses; update this block to populate ApiException.ResponseBody with a concise debug-friendly indicator (e.g., "<binary N bytes>" and optionally a short hex/snippet of the first 16 bytes) rather than the full binary payload, by reading __response.Content as a byte[]/stream to determine length and snippet before throwing, and ensure you still set ResponseHeaders and other fields; alternatively, if omission is intentional, add a brief comment in the catch explaining why ResponseBody is not set for binary responses.src/libs/AutoSDK/Extensions/MimeTypeExtensions.cs (1)
14-16: Consider expanding binary MIME type coverage.The current implementation handles
application/octet-stream,application/zip, andaudio/*. If this extension is intended for broader use across the SDK, you may want to consider adding other common binary types such asvideo/*,image/*, orapplication/pdf.If the current set is intentionally scoped to the ElevenLabs API responses (which are predominantly audio), this is fine as-is.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/libs/AutoSDK/Extensions/MimeTypeExtensions.cs` around lines 14 - 16, The current binary-detection logic in MimeTypeExtensions (the method that compares normalizedMimeType to "application/octet-stream", "application/zip" and "audio/*") is too narrow; update that method to also treat "video/*", "image/*" and "application/pdf" as binary by adding normalizedMimeType.StartsWith("video/", StringComparison.OrdinalIgnoreCase), normalizedMimeType.StartsWith("image/", StringComparison.OrdinalIgnoreCase), and normalizedMimeType.Equals("application/pdf", StringComparison.OrdinalIgnoreCase) (keeping the existing checks for audio, zip, and octet-stream).src/tests/AutoSDK.UnitTests/ResponseTypeInferenceTests.cs (1)
42-47: Cover the non-string byte[] path explicitly.These assertions prove byte[] inference, but they would still pass if the generator skipped
Process...ResponseContentwheneverReadResponseAsStringisfalse. Please add an assertion around the generated hook placement, or a runtime test that exercises bothReadResponseAsStringmodes, so this regression is covered.Also applies to: 75-78, 106-108
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tests/AutoSDK.UnitTests/ResponseTypeInferenceTests.cs` around lines 42 - 47, The test currently asserts byte[] inference via GeneratedEndPoint output (GenerateEndPoint) but doesn't verify that the generator emits the Process...ResponseContent hook when ReadResponseAsString is false; add an assertion that the generated code contains the response-processing hook placement (e.g., contains a call or method named "Process" + operation name + "ResponseContent" or the explicit "Process" method string used by the generator) when ReadResponseAsString == false, and add a complementary assertion or small runtime test that toggles ReadResponseAsString true/false to ensure the code path that calls ReadAsByteArrayAsync and returns __content is only present when the non-string branch is used; update ResponseTypeInferenceTests (the GenerateEndPoint-based assertions around GetAudioAsync/ReadAsByteArrayAsync/return __content) to include these hook-placement checks for the same cases around lines referenced (also replicate similar checks for the other two test blocks mentioned).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.MusicGenerationClient.CreateMusicDetailed.g.verified.cs:
- Around line 185-191: The non-ReadResponseAsString branch returns raw bytes
directly and skips the response-content hook; ensure the bytes are passed
through the same hook used in the ReadResponseAsString path by invoking
ProcessCreateMusicDetailedResponseContent(__response, __content, __headers) (or
the existing ProcessCreateMusicDetailedResponseContent method) before returning
from the method that currently returns __content; update the return path in
CreateMusicDetailed/ProcessCreateMusicDetailedResponseContent flow so both
branches apply the hook consistently (use the same parameters the
ReadResponseAsString branch provides).
---
Outside diff comments:
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/CLI/ultravox/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs:
- Around line 99-102: The else block in the CallsRecordingRetrieve test reads a
response stream into __contentStream_302 but never uses it; remove the unused
ReadAsStreamAsync call or wrap it in a using/dispose if you intend to consume it
(e.g., for logging). Locate the else branch that declares __contentStream_302 in
the CallsRecordingRetrieve-generated snapshot test and either delete the await
__response.Content.ReadAsStreamAsync(...) assignment or change it to a properly
disposed/used stream (or read to a string for logging) so the variable is not
allocated and leaked unused.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs:
- Around line 245-259: The CreateAudioIsolationAsync method builds a request
from parameters that are declared non-nullable (audio and audioname) but lacks
guard clauses; add explicit null checks at the start of
CreateAudioIsolationAsync to throw ArgumentNullException for audio and audioname
(use nameof(audio)/nameof(audioname)) before constructing the
global::G.BodyAudioIsolationV1AudioIsolationPost request so the method fails
fast and follows the project's parameter validation guidelines.
- Around line 193-206: The non-string branch currently returns raw bytes after
EnsureSuccessStatusCode without invoking the response-content hook; call
ProcessCreateAudioIsolationResponseContent (passing __response and the byte[]
__content) and use its returned/possibly-processed bytes before returning,
mirroring the string branch behavior; update the path around
EnsureSuccessStatusCode in the CreateAudioIsolation method to invoke
ProcessCreateAudioIsolationResponseContent with __response and __content and
return that value instead of the raw __content.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs:
- Around line 237-250: The non-string response path returns raw bytes without
invoking the post-processing hook; call
ProcessCreateMusicStemSeparationResponseContent before returning bytes in the
else branch. Specifically, after __response.EnsureSuccessStatusCode() and after
reading __content via __response.Content.ReadAsByteArrayAsync, invoke
ProcessCreateMusicStemSeparationResponseContent(__response, __content,
ReadResponseAsString) (or the overload used elsewhere) to run the partial hook,
then return the (possibly modified) byte[] result; mirror how the string path
around ProcessCreateMusicStemSeparationResponseContent is used to ensure
consistent behavior.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs:
- Around line 168-195: The else branch that returns the byte[] response misses
calling the partial hook
ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent, causing
inconsistent behavior vs the ReadResponseAsString branch; to fix, invoke
ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent in the else
branch after reading __content and before returning, passing the same parameters
used in the ReadResponseAsString branch (the response, the response content
representation used there, and any headers/status info) so implementers get the
hook in both code paths.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.AgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cs:
- Around line 127-172: The response processing hook
ProcessGetConvaiConversationsByConversationIdAudioResponseContent is only
invoked in the ReadResponseAsString branch and before EnsureSuccessStatusCode(),
so custom partials see failed responses in one path and no successful responses
in the other; fix this by collapsing the two byte[] paths into a single success
path: call __response.EnsureSuccessStatusCode() first, then read the bytes via
__response.Content.ReadAsByteArrayAsync(...) into __content, then invoke
ProcessGetConvaiConversationsByConversationIdAudioResponseContent(httpClient:
HttpClient, httpResponseMessage: __response, content: ref __content), and
finally return __content (preserving the ReadResponseAsString conditional only
if other behavior depends on it).
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cs:
- Around line 245-264: In the CreateAudioIsolationAsync convenience overload,
add explicit null checks for the audio and audioname parameters before
constructing __request: if audio is null throw new
ArgumentNullException(nameof(audio)) and if audioname is null throw new
ArgumentNullException(nameof(audioname)). Update the method
(CreateAudioIsolationAsync that builds the
global::G.BodyAudioIsolationV1AudioIsolationPost __request) to perform these
guards so invalid input is rejected rather than being converted to empty values
downstream.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.MusicGenerationClient.CreateMusicStream.g.verified.cs:
- Around line 154-157: The response post-processing hook
ProcessCreateMusicStreamResponseContent is only invoked when
ReadResponseAsString is true, causing consumers to miss the byte[] content hook
on the alternate success path; update the CreateMusicStream response handling so
that ProcessCreateMusicStreamResponseContent(httpClient: HttpClient,
httpResponseMessage: __response, content: ref __content) is called in both
success branches (the ReadResponseAsString true branch and the byte[] return
branch) before returning, ensuring both paths invoke the same post-processing;
do the same change for the other occurrence mentioned (the block around lines
181-191) so both success paths consistently call the hook.
- Around line 167-176: The generated exception drops the buffered response body
(__content) and only uses __response.ReasonPhrase; update the ApiException
construction in CreateMusicStream (where __response, __ex and __content are in
scope) to preserve the response payload by including __content: either append it
to the message passed to new global::G.ApiException or assign it to a
response-body property on the exception instance (e.g., set a
ResponseBody/Content property on the returned ApiException) and keep
ResponseHeaders as-is so unmodeled 4xx/5xx JSON/text payloads are retained for
diagnostics.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs:
- Around line 168-180: The else branch after reading the byte[] (__content) is
missing a call to the partial hook
ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContent,
causing consumers to miss the hook when ReadResponseAsString is false; update
the else branch in the
GetPronunciationDictionariesByDictionaryIdByVersionIdDownload response handling
to invoke
ProcessGetPronunciationDictionariesByDictionaryIdByVersionIdDownloadResponseContent(__response,
__content, __headers) (matching the call made in the ReadResponseAsString
branch) before returning __content so the partial method is always executed
regardless of ReadResponseAsString.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs:
- Around line 99-102: The else branch currently reads the response stream into
the unused local __contentStream_302 causing unnecessary I/O; either remove that
branch entirely or consume/dispose the stream content appropriately: locate the
302 error handling block where __contentStream_302 is assigned (the else branch
after the 302 response check) and either delete the await
__response.Content.ReadAsStreamAsync(...) call or replace it with code that
reads/disposes the stream (e.g., copy to a buffer, call ReadAsStringAsync, or
use a using/Dispose) so the stream is not leaked and no unused variable remains.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/SystemTextJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs:
- Around line 155-167: The response-content hook
ProcessCallsRecordingRetrieveResponseContent must be invoked regardless of
ReadResponseAsString; update the code paths in the method handling
CallsClient.CallsRecordingRetrieve (the branch that reads byte[] into __content
and the other byte[] branch) to call
ProcessCallsRecordingRetrieveResponseContent(__response, __content) before
returning, ensuring the hook runs for both byte[] flows and not only when
ReadResponseAsString is true; locate the usages around
__response.EnsureSuccessStatusCode(), the __content variable assignments, and
the early return statements and insert the hook invocation in both byte[] return
paths.
---
Nitpick comments:
In `@src/libs/AutoSDK/Extensions/MimeTypeExtensions.cs`:
- Around line 14-16: The current binary-detection logic in MimeTypeExtensions
(the method that compares normalizedMimeType to "application/octet-stream",
"application/zip" and "audio/*") is too narrow; update that method to also treat
"video/*", "image/*" and "application/pdf" as binary by adding
normalizedMimeType.StartsWith("video/", StringComparison.OrdinalIgnoreCase),
normalizedMimeType.StartsWith("image/", StringComparison.OrdinalIgnoreCase), and
normalizedMimeType.Equals("application/pdf", StringComparison.OrdinalIgnoreCase)
(keeping the existing checks for audio, zip, and octet-stream).
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cs:
- Around line 223-227: The current catch in CreateMusicStemSeparation throws
G.ApiException using only __response.ReasonPhrase, which loses server
diagnostics; update the throw to include the response body content when
available (e.g., read __response.Content.ReadAsStringAsync() and append or
interpolate it into the message for non-422 errors) while preserving the
existing innerException (__ex) and other exception fields so the full response
context is surfaced in G.ApiException.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs:
- Around line 154-166: The catch block that throws new global::G.ApiException in
GetPronunciationDictionariesByDictionaryIdByVersionIdDownload currently omits
ResponseBody for binary responses; update this block to populate
ApiException.ResponseBody with a concise debug-friendly indicator (e.g.,
"<binary N bytes>" and optionally a short hex/snippet of the first 16 bytes)
rather than the full binary payload, by reading __response.Content as a
byte[]/stream to determine length and snippet before throwing, and ensure you
still set ResponseHeaders and other fields; alternatively, if omission is
intentional, add a brief comment in the catch explaining why ResponseBody is not
set for binary responses.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_`#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cs:
- Around line 135-167: The flag ReadResponseAsString is misleading because the
code path reads a byte array; update usages and the flag name to reflect
buffered/binary handling (e.g., rename ReadResponseAsString to
ReadResponseBuffered or BufferResponseContent) and adjust all references in the
same generated client code path (including the conditional around
ReadResponseAsString and any related logic in
ProcessGetVoicesByVoiceIdSamplesBySampleIdAudioResponseContent and
response-returning methods) so the boolean name matches behavior, or change the
condition to a properly named flag in the generator template so generated
methods consistently use the new name.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cs:
- Around line 135-141: The flag ReadResponseAsString is misleading for binary
endpoints because both branches call ReadAsByteArrayAsync; update the generator
or surrounding code to either rename the flag to something like
ReadResponseAsBytes/ReadResponseAsBinary or add an inline comment/documentation
next to the ReadResponseAsString usage in the generated method (the conditional
block that reads __response.Content.ReadAsByteArrayAsync) clarifying that this
flag controls response reading behavior for binary payloads and that both
true/false branches will use byte-array reads for this endpoint; ensure
references to ReadResponseAsString in the method and any generation templates
(the conditional around ReadAsByteArrayAsync) are updated consistently.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_`#G.CallsClient.CallsRecordingRetrieve.g.verified.cs:
- Around line 141-153: The catch block that throws G.ApiException currently only
sets ResponseHeaders and loses response body content because content is a
byte[]; update the catch in the same method that builds the ApiException (the
catch handling __ex and constructing new global::G.ApiException) to attempt to
read __response.Content as a byte[] and then: if the bytes decode as UTF-8 (or
other expected text encoding) set the exception's ResponseBody to the decoded
string, otherwise set ResponseBody to a safe representation (e.g., base64 or
null) so binary payloads are preserved; ensure you use the existing
__response.Content and set the ResponseBody property on the created
global::G.ApiException before throwing.
In `@src/tests/AutoSDK.UnitTests/ResponseTypeInferenceTests.cs`:
- Around line 42-47: The test currently asserts byte[] inference via
GeneratedEndPoint output (GenerateEndPoint) but doesn't verify that the
generator emits the Process...ResponseContent hook when ReadResponseAsString is
false; add an assertion that the generated code contains the response-processing
hook placement (e.g., contains a call or method named "Process" + operation name
+ "ResponseContent" or the explicit "Process" method string used by the
generator) when ReadResponseAsString == false, and add a complementary assertion
or small runtime test that toggles ReadResponseAsString true/false to ensure the
code path that calls ReadAsByteArrayAsync and returns __content is only present
when the non-string branch is used; update ResponseTypeInferenceTests (the
GenerateEndPoint-based assertions around
GetAudioAsync/ReadAsByteArrayAsync/return __content) to include these
hook-placement checks for the same cases around lines referenced (also replicate
similar checks for the other two test blocks mentioned).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 53b25f34-df4e-43d8-9e97-5ffef5f16fde
📒 Files selected for processing (37)
src/libs/AutoSDK/Extensions/MimeTypeExtensions.cssrc/libs/AutoSDK/Models/EndPoint.cssrc/libs/AutoSDK/Models/EndPointResponse.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/CLI/ultravox/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.AgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.AudioIsolationClient.CreateAudioIsolationStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.IAgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.IAudioIsolationClient.CreateAudioIsolation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.IAudioIsolationClient.CreateAudioIsolationStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.ISamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusic.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusicDetailed.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.MusicGenerationClient.CreateMusicStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.SpeechHistoryClient.CreateHistoryDownload.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/NewtonsoftJson/_#G.StudioClient.CreateStudioProjectsByProjectIdSnapshotsByProjectSnapshotIdArchive.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.AgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.AudioIsolationClient.CreateAudioIsolation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.AudioIsolationClient.CreateAudioIsolationStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.IAgentsPlatformClient.GetConvaiConversationsByConversationIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.IAudioIsolationClient.CreateAudioIsolation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.IAudioIsolationClient.CreateAudioIsolationStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.ISamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.MusicGenerationClient.CreateMusic.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.MusicGenerationClient.CreateMusicDetailed.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.MusicGenerationClient.CreateMusicStemSeparation.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.MusicGenerationClient.CreateMusicStream.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.PronunciationDictionaryClient.GetPronunciationDictionariesByDictionaryIdByVersionIdDownload.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.SamplesClient.GetVoicesByVoiceIdSamplesBySampleIdAudio.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.SpeechHistoryClient.CreateHistoryDownload.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_#G.StudioClient.CreateStudioProjectsByProjectIdSnapshotsByProjectSnapshotIdArchive.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/NewtonsoftJson/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cssrc/tests/AutoSDK.SnapshotTests/Snapshots/ultravox/SystemTextJson/_#G.CallsClient.CallsRecordingRetrieve.g.verified.cssrc/tests/AutoSDK.UnitTests/ResponseTypeInferenceTests.cs
Comment on lines
+185
to
+191
| var __content = await __response.Content.ReadAsByteArrayAsync( | ||
| #if NET5_0_OR_GREATER | ||
| cancellationToken | ||
| #endif | ||
| ).ConfigureAwait(false); | ||
|
|
||
| return | ||
| await global::System.Text.Json.JsonSerializer.DeserializeAsync<byte[]?>(__content, JsonSerializerOptions).ConfigureAwait(false) ?? | ||
| throw new global::System.InvalidOperationException("Response deserialization failed."); | ||
| return __content; |
There was a problem hiding this comment.
Invoke ProcessCreateMusicDetailedResponseContent in the non-ReadResponseAsString path too.
Line 154-157 applies the response-content hook, but Line 185-191 returns raw bytes without that hook. This makes partial customization behavior inconsistent based on ReadResponseAsString.
Suggested fix
var __content = await __response.Content.ReadAsByteArrayAsync(
`#if` NET5_0_OR_GREATER
cancellationToken
`#endif`
).ConfigureAwait(false);
+ ProcessCreateMusicDetailedResponseContent(
+ httpClient: HttpClient,
+ httpResponseMessage: __response,
+ content: ref __content);
+
return __content;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| var __content = await __response.Content.ReadAsByteArrayAsync( | |
| #if NET5_0_OR_GREATER | |
| cancellationToken | |
| #endif | |
| ).ConfigureAwait(false); | |
| return | |
| await global::System.Text.Json.JsonSerializer.DeserializeAsync<byte[]?>(__content, JsonSerializerOptions).ConfigureAwait(false) ?? | |
| throw new global::System.InvalidOperationException("Response deserialization failed."); | |
| return __content; | |
| var __content = await __response.Content.ReadAsByteArrayAsync( | |
| `#if` NET5_0_OR_GREATER | |
| cancellationToken | |
| `#endif` | |
| ).ConfigureAwait(false); | |
| ProcessCreateMusicDetailedResponseContent( | |
| httpClient: HttpClient, | |
| httpResponseMessage: __response, | |
| content: ref __content); | |
| return __content; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/tests/AutoSDK.SnapshotTests/Snapshots/elevenlabs/SystemTextJson/_`#G.MusicGenerationClient.CreateMusicDetailed.g.verified.cs
around lines 185 - 191, The non-ReadResponseAsString branch returns raw bytes
directly and skips the response-content hook; ensure the bytes are passed
through the same hook used in the ReadResponseAsString path by invoking
ProcessCreateMusicDetailedResponseContent(__response, __content, __headers) (or
the existing ProcessCreateMusicDetailedResponseContent method) before returning
from the method that currently returns __content; update the return path in
CreateMusicDetailed/ProcessCreateMusicDetailedResponseContent flow so both
branches apply the hook consistently (use the same parameters the
ReadResponseAsString branch provides).
This was referenced Mar 16, 2026
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
1 participant
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.
Summary by CodeRabbit
New Features
Bug Fixes
Tests