dc/docs.datacontroller.io
6
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(troubleshooting): document the browser_info support diagnostics

Browse Source 
Every service call carries a single-row browser_info input table, readable
by any service or hook script as work.browser_info and dumped to the job log
when debug is on. Document its columns and how to see it, so a support ticket
can be answered from the log without follow-up questions.
This commit is contained in:
dc
2026-09-24 20:29:30 +00:00
parent c21f413f06
commit 2a65664a51
1 changed files with 34 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dci-troubleshooting.md
+34 -1
View File
@@ -140,4 +140,37 @@ Then recycle any existing compute sessions - hot sessions keep the old setting u
The app version is bundled into the frontend during the release, and is visible by clicking your username in the top right.
You can also determine the app version (and SASjs Version, and build time) by opening browser Development Tools and running `appinfo()` in the console.
You can also determine the app version (and SASjs Version, and build time) by opening browser Development Tools and running `appinfo()` in the console.
## Support Diagnostics
Every service call the frontend makes carries a single-row `browser_info` input table, available to the service (and to any [hook script](macros.md)) as `work.browser_info`. It records where the request came from, so a support ticket can be diagnosed from the job log without asking the user follow-up questions, and a hook can adapt to its context.
The table has these columns:
| Column | Description |
|---|---|
| `url` | The URL of the Data Controller page itself (the iframe), not the document embedding it. When the editor is embedded in a report, any parameters the report author added to the embed URL are visible here. |
| `referrer` | The embedding document, from `document.referrer`. For an embedded report this is the report URL, so the embedding report can be told apart from the editor URL. |
| `timezone` | The browser's IANA timezone name, e.g. `Europe/Berlin`. |
| `tz_offset` | The browser's UTC offset in minutes, as `Date.getTimezoneOffset()` returns it (positive west of UTC, so `Europe/Berlin` in summer is -120). |
| `locale` | The browser locale, e.g. `en-GB`. |
| `dc_version` | The Data Controller build, as shown by `appinfo()`. |
| `adapter_version` | The `@sasjs/adapter` version the client was built with. |
| `browser` | The browser family, parsed from the user agent. |
| `browser_version` | The browser version. |
| `platform` | The operating system, parsed from the user agent. |
| `user_agent` | The raw `navigator.userAgent` string. |
The values are supplied by the client, so treat them as diagnostics hints rather than a security boundary.
To see the table, run any request with debug on (for example add `&_debug=131` to the service URL). The session initialisation then writes the row to the job log:
```
NOTE: MPEINIT: work.browser_info:
url=... referrer=... timezone=Europe/Berlin tz_offset=-120 locale=en-GB
dc_version=7.15.0 adapter_version=4.19.0 browser=Chrome browser_version=120.0
platform=Linux user_agent=...
```
The table is sent by newer clients only. A service called directly (for instance from a URL, or by a script), or by an older frontend, has no `work.browser_info` - the log then records that fact instead.