>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3505192. --> Reported by: [andrewbelcher](https://www.drupal.org/user/655282) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The Bedrock provider sets the <code>ChatOutput</code> <code>$rawOutput</code> param with the direct response from the AWS SDK, which means it's an <code>Aws\Result</code>. This then fails to get <code>json_encode</code>d in the logger, so you end up with <code>{}</code> in the output.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>Enable the AWS Bedrock provider and AI logging with output logging enabled, and trigger a request. View the log, the output will always be <code>{}</code>.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Not quire sure, thoughts are one of:<br> 1. AWS Bedrock Provider should set <code>$response-&gt;toArray()</code> as the raw output. This might not be ideal for direct use though, as the AWS response object may have a use.<br> 2. Logger should do some detection on the data type and figure out ways to handle types that don't directly encode. This isn't ideal as it makes them dependent on lots of other types etc...<br> 3. Logger should use normalised output for logging, but this will lose additional provider specific metadata...<br> 4. We should add an extra property to <code>ChatOutput</code> that always contains the raw data in a consistent data type. This means the provider is responsible for conversion, but means storing yet another copy of data.<br> 5. AWS could extend <code>ChatOutput</code> to store the AWS DTO, expose is via a new method, and do a <code>toArray</code> for <code>getRawOutput</code>.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3>