SSO Job Log // Transmission 1615/CorpNet

SSO-usually easy creds. Spin up the IdP, toss in some accounts, wire up a few groups, maybe sprinkle some SAML-done. Corporate® credit secured.

Not this cycle. Docs? Straight dog water. Get the accounts in, half the identity file crashes out with <<can’t override local id>>. Drop into the admin console, run some deep packet scrying, and find the real enemy: some ancient config lopping off the first two bytes of every ID. Can’t patch. Can’t override.

Solution? Ctrl+A → DEL. Nuked 1100 accounts like yesterday’s malware. Cave-man SFTP, shove in a fresh file, and suddenly the system purrs with proper IDs.

But now I’m feeding 6k identities a night into a box that feels like it’s running on a Cold War repurposed nuke mainboard. Chokes on anything over 500 rows per file. 1k? Dead. 750? Dead. 500? Yes, queen.

To make it worse, the filename spec is peak Corp® masochism:

YYYYMMDDHHMM-identity.csv

So I split the payload at 16:15, generate 12 shards as 1615-identity-01.csv … 1615-identity-12.csv. Extra archival file for my own records: 1615-identity.csv.

All good-until the devs drop their next surprise. Turns out the file index can’t end in a divisible by 10. My 10th shard? Ghosted from import. Now we code around the superstition and skip the tens.

And that’s the state: fragile legacy infra, duct-taped compliance, Cold War iron. Still running. Still importing. Still winning.

Lesson: brittle legacy pipelines mean you’re not just fighting code, you’re fighting entropy. Split jobs early and plan for arbitrary constraints.

Corporate® Deep state. Same circuit.

- HotChip