This PR mainly moved logic directly from conversation API v1 to v2 with
following changes:
- Return nullopt when completion content is empty in
ParseOAICompletionResponse. It shouldn't lead to a completion event
with empty string in conversation API cases, as we currently see
responses with tool_calls where content is empty string. This would
just make v2 follow the v1 behavior. For OAI, we return empty
completion event in OnQueryCompleted anyway, so it doesn't change
the behavior. The behavior change on OAI is we wouldn't fire
completion event in OnQueryDataReceived if content is empty, but it
does make sense in this case as there is no point fire it.
Also Extract GetOAIContentContainer for future usage.
- Copy and migrate tool handling logic from v1 to v2:
1. Tool Calls Now Belong to Messages, Not Events (oai_message_utils.h)
- Added tool_calls field to OAIMessage struct for assistant messages
- Added tool_call_id field for tool result messages (role="tool")
2. Message Serialization (conversation_api_v2_client.cc)
- Tool calls now accessed from message.tool_calls instead of event.tool_calls
- Tool calls and tool_call_id set on message_dict instead of event_dict
- Removed the special "toolCalls" type that was used when messages had both content and tool calls
3. Message Building (oai_message_utils.cc)
- Tool calls are now accumulated in the assistant message's tool_calls array
- The assistant message is added to the list first
- Tool results are then added as separate messages with role="tool" after the assistant message
- Previously, tool results were added as separate events in a flat structure
4. Tool Call Parsing (conversation_api_v2_client.cc)
- Tool calls now parsed from inside choices[0].delta.tool_calls or choices[0].message.tool_calls
- Previously looked for tool_calls at the top level of result_params
Bottom Line
The v2 implementation now properly follows OpenAI's message format where:
- Assistant messages contain tool_calls arrays
- Tool results are separate messages with role="tool" and tool_call_id
- This replaces the flatter event-based structure from v1
Logics and code structures are kept the same as v1 as much as possible
to help with review and easier transition.
- Migrate existing unittests, no new tests for oai_message_utils as
it's well covered in existing engine consumer and api_client unit
tests.
Only retry confirmations when the error is potentially transient.
Treat response codes as follows:
2XX: success
4XX: permanent failure (do not retry)
anything else: retry
Only retry token requests when the failure is potentially transient.
For POST /v3/confirmation/token/{paymentId}:
201: success
4XX: do not retry
anything else: retry
For GET /v3/confirmation/token/{paymentId}?nonce={nonce}:
200: success
4XX: do not retry
anything else: retry
* [ads] Improve POST /v4/confirmation/{transactionId} retry logic
Only retry confirmations when the error is potentially transient.
Treat response codes as follows:
2XX: success
4XX: permanent failure (do not retry)
anything else: retry
* [ads] Improve /v3 confirmation retry logic
Only retry confirmations when the error is potentially transient.
For POST /v3/confirmation/{transactionId}/{credential}:
2XX and 418: success
4XX: permanent failure (do not retry)
anything else: retry
For GET /v3/confirmation/{transactionId}/paymentToken:
200: success
4XX: permanent failure (do not retry)
anything else: retry
[ads] Add brave_ads/core/browser/network target
This PR organizes brave_ads/core/browser/service
to move network related files to a separate target.
This is a pre-requisite for moving Brave Ads code under
a build flag.
This simply adds the `brave-ai-chat-allow-private-ips` feature flag to iOS's `brave://flags` page which will be useful in future implementations of custom models in iOS
Improves code health by applying IWYU to clean up include usage and
commenting out unused parameters to reduce warnings, improve
readability, and keep the ads codebase easier to maintain.
Only retry catalog requests when the failure is potentially transient.
Treat response codes as follows:
200: success
4XX: do not retry
anything else: retry
Only retry requests when the failure is potentially transient.
Since this endpoint is served via CloudFront:
200: success
4xx: permanent failure (do not retry)
anything else: retry
Tests were passing because the CreateRewardConfirmation endpoint didn’t
validate HTTP response codes. Now that #51203 properly checks responses,
we need to ensure the credential is created correctly so the
confirmation request succeeds and the tests reflect expected outcomes.
BuildCreateRewardConfirmationUrlPath should use confirmation for
transaction id and credential, and unnecessary url request mocks were
removed since they were not needed.
The PR adds Brave Ads buildflag checks to
Brave Wallet and Brave Tor code which depend
on Brave Ads. This is a pre-requisite for moving
Brave Ads code under a build flag.
* Remove direct access to Browser(View) from BraveBrowserViewLayout
Upstream has introduced BrowserViewLayoutDelegate to avoid direct access
to Browser(View) from BrowserViewLayout.
In favor of this change, move all the logic that depend on Browser(View)
from BraveBrowserViewLayout to BrowserViewLayoutDelegate.
BrowserViewLayoutDelegate is a new class that is responsible for
providing the necessary information to BraveBrowserViewLayout.
During a recent recovery, we saw a high volume of v4 redemption retries
submitted over a short period. Since the max retry backoff is capped at
1 hour, queued retries from running browsers are retried within the same
1-hour window, concentrating traffic and increasing database load.
Classify HTTP status codes into high level classes so callers can make
consistent decisions (like retry vs fail fast) without handling every
individual status code.
Resolvesbrave/brave-browser#51939
This PR moves the code away from storing the encoded extrinsic.
The main motivation for this change is because decoding it reliably and well
relies on the chain metadata which is asynchronously fetched and currently,
all of the code that parses the transaction JSON from the backing data files
assumes a world of purely synchronous code.
Instead of opting into async data sources, we simply update the code to eschew
it by storing a more normalized format of rote data.
The code also updates the transaction metadata to store an ss58 prefix if the
send address was ss58-encoded. This is done so that we can store the recipient
address in its plain hex form and then reconstruct it on the front-end so that
what's displayed now matches perfectly with what the user originally typed in.
* Script changes to copy XTB files for Brave Origin
This is done when rebasing Chromium with `npm run chromium_rebase_l10n`
* Update GRD file to use Brave Origin's own XTB files
* Lint fix
Jocelyn Liu