gitzcreations/openvisengine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

worklog: Task 46 — directory env + db recovery after sandbox reprovision

Browse source 
The Directory tab's NOT_CONFIGURED message was the sandbox disk reset
wiping the untracked .env (OVE_DIRECTORY_URL/API_KEY) — not repo
corruption. Credentials restored from the project's cards; the deleted
custom.db was recovered from the running process's file handles before
restart (106 presets, 8 folders, settings intact); poisoned Turbopack
cache cleared; dev server restarted via dev.sh. secrets/ house-account
cookies remain lost (graceful fallback) — flagged for manual restore.
No code changes.
This commit is contained in:
zai-bot 2026-11-06 07:32:56 +00:00
parent 4d5fba3977
commit 737437a593
1 changed files with 26 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
worklog.md
View file

@ -2530,3 +2530,29 @@ BROWSER E2E (agent-browser, ALL PASS):
Stage Summary: Stage Summary:
- v7.15.2 shipped: the footer's right-hand group carries the project's Facebook page link (facebook.com/openvisengine, icon-only, new tab) beside the version stamp; the light/dark tick switch moved from the header to the Settings tab's Appearance section (first row, above the base-theme cards) with identical mechanics -- checked = white theme, unchecked = the visitor's stored dark base, both persist. Browser E2E green across link, relocation, flip behavior, stored-base tracking, What's New, responsiveness and the sticky footer. - v7.15.2 shipped: the footer's right-hand group carries the project's Facebook page link (facebook.com/openvisengine, icon-only, new tab) beside the version stamp; the light/dark tick switch moved from the header to the Settings tab's Appearance section (first row, above the base-theme cards) with identical mechanics -- checked = white theme, unchecked = the visitor's stored dark base, both persist. Browser E2E green across link, relocation, flip behavior, stored-base tracking, What's New, responsiveness and the sticky footer.
---
Task ID: 46
Agent: main (Z.ai Code)
Task: v7.15.2 ops restore (user report): "Why is the Directory Tab showing 'OVE-Directory is not configured on this server.' We have set this up in a previous version, did it get corrupted or lost?" + credentials cards supplied (Google Drive: API Reference + Connection Card).
Diagnosis (nothing was corrupted in the repo -- the SANDBOX was reprovisioned):
- The directory config lives in .env (OVE_DIRECTORY_URL + OVE_DIRECTORY_API_KEY), which has been deliberately UNTRACKED (gitignored) since the GitLab sync. The sandbox disk was reset when this session booted (05:11): the bootstrap rewrote .env to just DATABASE_URL, and the previous untracked .env with the key was lost with the old disk. Same wipe took the untracked db/ (custom.db) and secrets/ (house-account music-service cookies).
- The app kept working after the wipe because the running next-server held OPEN file handles to the deleted db inode -- every API call queried a file that no longer existed on disk. Any restart would have broken the database too.
- The directory VPS itself was never down: upstream GET /status answered 200 (service ok, uptime ~25 h, 2 scripts stored). Only the local proxy config was missing.
Recovery:
- .env restored from the credentials cards: OVE_DIRECTORY_URL=https://s3374dir.openvisengine.com + OVE_DIRECTORY_API_KEY (from the card; value intentionally not recorded here -- .env stays untracked/gitignored, never in the repo).
- Database RECOVERED from the deleted inode: cat /proc/<pid>/fd/<n> > db/custom.db off the running next-server's handles (single-file journal mode, no WAL sidecars) -- 307,200 bytes, SQLite header valid, PRAGMA integrity_check ok, contents intact: 106 presets, 8 folders, 1 settings row. The recovered snapshot now lives on disk, so restarts are safe.
- secrets/ house-account cookies: NOT recoverable (no open handles; they were files read per-request). Graceful degradation as designed -- the house cookie is only a FALLBACK for stream-a-link; everything else works. Needs the operator's cookie files restored by hand if the house account is wanted again.
- Dev server restarted via the platform's .zscripts/dev.sh (setsid-detached so the tree survives command boundaries): first manual attempt died with a corrupted Turbopack cache (the platform's git checkouts poisoned .next task data -- cleared with rm -rf .next) and a second attempt died with the tool session's teardown (pipe children not session-detached). Clean dev.sh start: health check passed. dev.pid refreshed.
BROWSER E2E (agent-browser, ALL PASS):
- GET /api/presets: full 106-preset library from the RECOVERED on-disk db (fresh process, not the deleted inode).
- GET /api/ove-directory/status: upstream envelope verbatim (service ok, 2 scripts, uptime ~25 h) -- NOT_CONFIGURED is gone.
- GET /api/ove-directory/scripts: authenticated proxy returns both community scripts ("Spectrum Bars" avg 3.3 / 4 votes, "Thick Spectrum Bars" avg 5.0 / 2 votes).
- Directory tab in the browser: active, no configuration error, both script names visible.
- Console: 0 errors / 0 warnings; canvas renders; footer version 7.15.2. Test browser closed.
Stage Summary:
- Directory tab restored: the sandbox reprovision (not corruption) had wiped the untracked .env holding OVE_DIRECTORY_URL/OVE_DIRECTORY_API_KEY; credentials re-entered from the project's cards, the deleted custom.db was recovered live from the running process's file handles before restart (106 presets/folders/settings intact), Turbopack cache cleared after the platform's git-checkout poisoning, dev server restarted via dev.sh. House-account cookies (secrets/) remain lost by design's graceful fallback -- flagged to the operator for manual restore if wanted.