Hi Adem,
Would you please take a look?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
db_.set_error_callback(base::BindRepeating([](int error,not sure, would like your input: What's the reason for using `NOTREACHED` compared to `(D)LOG` statements that do not crash?
if ((error & 0xff) == 19) { // SQLITE_CONSTRAINTdoes 0xff mean a constraint violation?
NOTREACHED() << "CapabilitiesDatabase SQLite Error: " << errorI think use (D)LOG here to log runtime errors in the callback without causing a crash
CHECK(false) << first_error;I am wondering if we should loop in the finch team to add a check there that checks the string's integrity before it hits here. Is there a way to check that? I think a broken string will crash the browser for all users running that finch experiment. Maybe we should add a log statement here to keep track of that?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
-CCs (sorry for the noise caused by uploading a bad rebase)
db_.set_error_callback(base::BindRepeating([](int error,not sure, would like your input: What's the reason for using `NOTREACHED` compared to `(D)LOG` statements that do not crash?
This code is targeted at developers. Getting a crash was easier to interpret than looking for the reason of absent data. But agreed, I'll DLOG it since it barely affects the user's browsing experience to not have old recordings.
if ((error & 0xff) == 19) { // SQLITE_CONSTRAINTdoes 0xff mean a constraint violation?
& 0xff just gives the relevant bits for the error code — the entire error code would give me the extended error which I don't need.
19 is the error code for `SQLITE_CONSTRAINT` — so if foreign key or unique constraints would be broken ... I can also DLOG that to make it more clear.
NOTREACHED() << "CapabilitiesDatabase SQLite Error: " << errorI think use (D)LOG here to log runtime errors in the callback without causing a crash
I'll use DLOG everywhere — I am always unsure when that's appropriate since the styleguide discourages all LOGs.
CHECK(false) << first_error;I am wondering if we should loop in the finch team to add a check there that checks the string's integrity before it hits here. Is there a way to check that? I think a broken string will crash the browser for all users running that finch experiment. Maybe we should add a log statement here to keep track of that?
There is no immediate plan to roll this out via Finch but I agree that the prospect of crashing every Chrome client on startup because of a typo is just a path that shouldn't exist. I'll make this a DumpWithoutCrashing.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Friedrich Hauser removed siyua+aut...@chromium.org, tbarzi...@chromium.org, thegreenf...@chromium.org, scheduler...@chromium.org, spang...@chromium.org, suetfei+wa...@google.com, torne...@chromium.org, tmartino+tran...@chromium.org, shuche...@chromium.org, trewin...@google.com, vakh+safe_br...@chromium.org, twifka...@chromium.org, security-...@chromium.org, thefro...@chromium.org, stanfie...@google.com, translat...@chromium.org, shend...@chromium.org, ukai+...@chromium.org, speed-metr...@chromium.org, tracing...@chromium.org, srahim...@chromium.org, storage...@chromium.org, sloboda...@chromium.org, tburkar...@chromium.org, subresource-f...@chromium.org, tgupta...@chromium.org, vaapi-...@chromium.org, sky+...@chromium.org, tommyw+w...@chromium.org, titoua...@chromium.org, tluk+...@chromium.org, shgar+aut...@google.com, servicewor...@chromium.org, siashah+au...@chromium.org, twelling...@chromium.org, shannc...@chromium.org, speed-metrics...@chromium.org, telemetr...@chromium.org, tranbaod...@chromium.org, toshikikikuchi+...@chromium.org, steimel+...@chromium.org, stevenjb+wa...@chromium.org, shimazu+se...@chromium.org and shimazu...@chromium.org from reviewers of this change.
[RecordReplay] Refine database seeding with error logging and comments
Why this change is necessary:
- Fixes a database corruption hazard by changing the background task
runner shutdown behavior to BLOCK_SHUTDOWN.
- Prevents silent database failures by adding an SQLite error callback.
- Adds extensive intent documentation across the seeding codebase.
Seeding formats supported:
1. Detailed Syntax: Seeding via a JSON file containing an explicit list
of steps with individual descriptions and expected data keys.
2. Quick Syntax: Seeding via a JSON file containing top-level
instructions or anchored messages only, which automatically
synthesizes a single step (Step 1) to maintain schema uniformity.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Friedrich Hauser removed pushi+watc...@google.com, wangdanny+watch-in...@google.com, schedule...@chromium.org, zackha...@chromium.org, vinnypersky+...@google.com, roagarw...@chromium.org, yhanada+...@chromium.org, yusufo...@chromium.org, rkgibso...@chromium.org, rsleev...@chromium.org, yuzo+...@chromium.org, zelin+watch-we...@chromium.org, xlythe+wa...@google.com, scheduler-...@chromium.org, vasilii+watchlis...@chromium.org, wychen...@chromium.org, yfriedm...@chromium.org, zol...@webkit.org, yongshun+...@google.com, rmcelra...@chromium.org, webap...@microsoft.com, roblia...@chromium.org, yyhyyh+fee...@google.com, webapks-...@chromium.org, pushi+wa...@google.com, wnwen...@chromium.org, ydago...@chromium.org, wangdanny+fe...@google.com, xiangdongkong+...@google.com, yhanada...@chromium.org, wfh+...@chromium.org, ramyagopa...@google.com, pushi+wat...@google.com, rainhar...@chromium.org, xiaochen...@chromium.org, xinghui...@chromium.org, webauthn...@chromium.org, rayanka...@chromium.org, yigu+...@chromium.org, rhalava...@chromium.org, yhanada+...@chromium.org, rsesek...@chromium.org, weiluanw...@google.com, video-networking...@google.com, yuezhang...@chromium.org, rrsilva+wat...@google.com, rginda...@chromium.org, yhanad...@chromium.org, yyhyyh+watch-inpu...@google.com and web-schedulin...@chromium.org from reviewers of this change.