Skip to content

"Corrupt log entry" when history contains legacy repeating-task occurrence IDs (<UUID>-YYYYMMDD) #4

Description

@maximilliangeorge

Problem

Running any command aborts with:

Corrupt log entry at ~/Library/Application Support/things3/append-log/things.log byte 3224757: data did not match any variant of untagged enum OneOrMany at line 1 column 1094

Cause

Things Cloud histories that go back far enough (mine has entries from 2017) contain IDs of the form <UUID>-YYYYMMDD, e.g.:

5F3AE5FB-3FF3-49DE-BF34-91224AACC9FF-20170524

Old Things clients used these for spawned occurrences of repeating tasks — the occurrence gets the template's UUID plus a date suffix, and references the template via rt. These IDs appear both as object keys and inside relationship arrays (ts, rt).

ThingsId::from_str only accepts plain UUIDs, ACTIONGROUP-<UUID> (since #3), and compact base58 — so the first log line containing such an ID fails to deserialize as WireItem and fold_state_from_append_log bails, making the CLI unusable for affected accounts.

This is the same class of legacy-ID issue as #3.

Fix

The parser should accept the <UUID>-YYYYMMDD shape. Note the date suffix must not be stripped (unlike the ACTIONGROUP- prefix): the occurrence is a distinct entity from its template, so it needs to canonicalize to its own distinct 16 bytes — e.g. by SHA1-hashing the full uppercase string, the same scheme legacy UUIDs already use.

PR incoming.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions