Have something to say?
Exported PDFs show US-format dates in the header
The metadata header on an exported PDF renders the date in US format — Date: 1/27/2025, 7:05:46 PM — while dates inside the item body are in the original UK long form, e.g. On Sun, 26 Jan 2025 at 18:13. For a UK disclosure that's confusing at best and ambiguous at worst: 1/2/2025 reads as 2 January to the recipient and 1 February to us. Likely cause The header date is formatted at conversion time; a locale defaulting to en-US rather than en-GB would produce exactly this. Reported in support conversation 197.
Wide tables are silently cut off in exported PDFs
When an item contains a table wider than the printed page, the exported PDF silently loses the columns that overflow the right-hand margin. The customer gets a document that looks complete but isn't, with no warning anywhere. What happens We render items to PDF at A4 with 1cm margins. Chromium shrinks over-wide content to fit up to a bounded factor and then simply clips whatever is left. The clipped text is not drawn on the page and is not in the PDF's text layer, so it cannot be found, redacted, searched or recovered. Real example A delivery-exception report pasted from Excel into Outlook: 14 columns, roughly 1850px wide. The exported PDF prints as far as "Address 2" plus two characters of the postcode. Category, Issue, Repeat, the free-text Comment and Closed are gone from every row. One cell that reads Admin-Mitcham-039-Customer contacted for delivery instructions not followed on 23/01... prints as Admin-Mitcham-0 and stops. Why it matters This is a data-completeness problem on a disclosure product. Items are exported for DSARs and legal disclosure, so handing over a document with content missing is worse than failing loudly — and nothing currently tells anyone it happened. It also produces a confusing second-order effect: a term can be redacted successfully in the interface while no black box ever appears, because the text it matched is not on the page at all. Suggested direction Detect and flag first — cheap, and turns a silent loss into a visible one. At conversion, compare the rendered text against the source and warn on the item when content did not fit. Then remedy — render items that overflow in landscape, or scale the page down further for wide content, so the columns actually print. Raised from support conversation 583, where the missing text was found while investigating a separate export-gate problem (now fixed).
Deleted files leave source uploads and attachment blobs in storage
When a file is deleted, the database rows are removed and the logs report success, but the underlying objects stay in Cloud Storage indefinitely. Evidence (production, 16 July deletion, still present 20 July) Logs show the full happy path: Attachments cleaned up and unreferenced blobs queued for reap, Starting async PDF cleanup, File deleted successfully. Despite this, thousands of attachment blobs remain under the project's attachments/ prefix in the uploads bucket. The original uploaded source files also remain under the user's uploads/ prefix — they do not appear to be removed by the delete path at all. Four days later none of these objects have been reaped. Why it matters This is a retention and data-protection gap, not just wasted storage. A customer who deletes their content — often the whole point of a redaction workflow — still has the original documents and attachments held on our infrastructure, including personal data belonging to third parties. Deletion must actually delete. Suggested next step Verify the reap queue is receiving rows and is actually being drained, confirm the delete path removes the source upload as well as attachments, and backfill a cleanup for objects already orphaned by past deletions.
File deletion intermittently returns 500 before eventually succeeding
Deleting a file from a project intermittently fails with a 500 before a later retry succeeds. Observed repeatedly on 15-16 July in production. Evidence One file returned 500 on four consecutive delete attempts, then succeeded. A second file returned 500 twice before succeeding. A third returned 500 twice the previous day. One delete returned 200, and an immediate repeat of the same request returned 404 — so the client cannot tell a real failure from an already-completed delete. Why it matters Deletion is a data-protection operation. A customer clearing their own content sees an error and cannot tell whether the data was removed. Repeated retries also mean the cleanup path runs more than once for the same file. Suggested next step Capture the underlying error behind the 500 (the response body is generic), make the delete idempotent so a repeat returns success rather than 404, and surface a clear outcome to the user.
Blank Pages at the beginning of PDF Exports
Fixed and deployed. Blank pages at the start of an exported PDF were caused by how documents authored in Word/Outlook declare their page layout: it forced a page break that left the document header alone on the first page, with the content pushed onto the next page (and, for multi-section messages such as bounce notifications, over several pages). The exporter no longer honours that author-supplied page layout, so the header and content now start together on page one. Genuine, deliberate page breaks are still respected. Note: this applies to documents processed from now on. PDFs that were already exported keep their existing layout — re-exporting the affected documents produces the corrected version.
Wordlist redact numbers are all over the place
When doing a redaction using a wordlist, the numbers it shows are all over the place. For example, for one keyword it shows 250 matches across 100 items. Then, when inspecting, it shows “Redact 4223 matches” Then, when clicking the “Redact 4233 matches” it changes to a confirm button: “Redact 4223 matches of 40”
Increase upload rate limit
When trying to upload many files, I get the error: Upload Rate Limit You're uploading too quickly. Please wait 30 seconds before uploading more files. This really shouldn’t be happening - the whole point of this application is to upload many files and emails! Either the rate limiting should be handled transparently, or the limit should be removed?
Make email body links open in new tab by default
When clicking links in email body, they should probably open in a new tab by default - otherwise it’s very frustrating to have to come back find your place again when going back to triage/redaction.
[bug] Password protected PDF attachments cause locked out display
When a PDF attachment is password protected, the page prompts you for a password. When this is cancelled, it just prompts again, soft locking the page until you refresh.
Implement stable sorting algorithm / Multiple column sorting
When you sort emails by a column that has a lot of duplicate values (e.g. sorting by “From”) and then take an action on an email, the order of the emails can jump around randomly. The emails should remain in the same order, even if one is triaged. This could be solved by including a final ordering param (e.g. always have a final order by ID or date). It would also help to be able to sort by multiple columns, e.g. From ASC subject ASC
Changing page size removes inbox multi selection
We are processing some large inboxes (> 2GB) across multiple files. It is essential to be able to multiple select those inboxes to work on them all at once. When changing the page size (e.g. from 50 to 100) the multiple selection of inboxes is removed.
Bulk actioning on emails (>~200 selected)
When doing a bulk action on >200 emails approx, it comes up with a 400 error: Failed to perform bulk action: Request failed with status code 400 The only way to do is a page at a time at the moment. There is a corresponding logged error: location: "body" msg: "Invalid value" path: "emailIds" type: "field" With a bunch of email ids
Body "Does not contain" filter does not work
I’m trying to filter an email list by Body and Does Not Contain and it doesn’t seem to be working. Body “contains” works fine, but “does not contain” does not seem to filter at all.