A JSON queue with no database holds up, if unclassified items land mid-rank not last

A write-up on dev.to describes a YouTube long-form publishing queue that is nothing more than JSON files committed to a repository directory, content/yt-longform-queue/, with no external queue service, no database rows and no management dashboard ^[1][2]. The author reports three months without a major incident, which matters less as a durability claim than as a map of where the complexity actually went: into the file picker ^[3].

The mechanics are deliberately dull. A generator script commits a spec file, the publish workflow picks one, renders it to MP4, uploads it, then moves the file to an uploaded/ directory ^[4]. The interesting part is selection order. According to the author, first-in-first-out breaks as soon as product walkthroughs, educational deep-dives and weekly recaps sit in the queue at the same time: a recap committed yesterday would block a product walkthrough committed two weeks earlier, and product content is what grows the channel ^[5][6].

So the picker carries an explicit rank table. product_findindiegame is 0, product_ossfind and hidden-gem are 1, build_in_public is 2, technical is 3, curated and meta are 4, contrarian is 6, recap and ai_tools are 7 ^[7]. Within a tier, files sort by filename, oldest first ^[8]. The archetype comes from a top-level field in the spec JSON, with a filename prefix match as fallback for older files that predate the field ^[9].

The load-bearing line is DEFAULT_RANK = 5 ^[10]. An archetype the author has not classified yet lands in the middle of a range that runs 0 to 7, ahead of three of the ten named archetypes and behind seven ^[11]. The stated effect is that new formats still air rather than sitting perpetually at the end of the queue ^[12]. That is the whole trick. A taxonomy where unknown means last is a taxonomy that starves every experiment behind the formats it has already blessed, and the person maintaining it will not notice, because nothing errors. The bill for this design is that adding a name to the dict can reorder the queue overnight, which the author says he has done on purpose to let a backlogged product video jump a stale recap ^[13].

The second constraint is expiry. Files carry a YYYY-MM-DD prefix and the picker deletes anything older than 21 days before selecting, on the grounds that a three-week-old spec may cite star counts, model download numbers or pricing tiers that have moved ^[14][15]. The threshold is overridable through an environment variable set as a GitHub Actions secret ^[16]. The trap is symmetric: pause publishing for longer than 21 days and specs expire silently with nothing airing, so the fix is to re-date the file after re-reading it ^[17]. The author says he lost two specs this way just after adding generated keyart thumbnails to them ^[18]. Against a Tue/Thu/Sat cron at 23:00 UTC, the window allows roughly nine scheduled drain attempts before a spec ages out ^[19][20].

Two smaller pieces keep the signal honest. An empty queue exits 0 with a skip output, every later step is gated on it, and the run goes green in about 30 seconds instead of showing red on every quiet cron ^[21][22][23]. A concurrency group with cancel-in-progress set to false queues a push that arrives mid-render rather than killing it, so two runs cannot pick the same file during a 12 to 18 minute render ^[24][25].

What to watch is the gap the default rank creates. The write-up describes no validation that an archetype string matches a key in the table, and under a mid-range default a typo is scheduled identically to a genuinely new format ^[26]. That is a tolerable failure while one person owns both the generator and the dict. It stops being tolerable the moment a second contributor writes a spec.