Null Analysis ID Generation Breaking Analysis Links done claude analysis:8 coding:7 reasoning:7

Root cause: The system is generating analysis links with 'None' as the analysis ID instead of proper analysis identifiers. This suggests a bug in the analysis ID generation or link construction code where a variable is None when it should contain a valid analysis ID. Fix strategy: Examine the code that generates analysis links in templates and API endpoints. Look for variables like `analysis_id`, `analysis.id`, or similar that might be None. Check: 1) Template files that create analysis links - ensure proper null checking and fallback values, 2) API endpoints that return analysis data - verify analysis objects have valid IDs before serialization, 3) Analysis creation code - ensure IDs are properly generated and saved to database. Add null checks and default to analysis title slugs or timestamps as fallback IDs. Affected links (1): - /analysis/None ## REOPENED TASK — CRITICAL CONTEXT This task was previously marked 'done' but the audit could not verify the work actually landed on main. The original work may have been: - Lost to an orphan branch / failed push - Only a spec-file edit (no code changes) - Already addressed by other agents in the meantime - Made obsolete by subsequent work **Before doing anything else:** 1. **Re-evaluate the task in light of CURRENT main state.** Read the spec and the relevant files on origin/main NOW. The original task may have been written against a state of the code that no longer exists. 2. **Verify the task still advances SciDEX's aims.** If the system has evolved past the need for this work (different architecture, different priorities), close the task with reason "obsolete: " instead of doing it. 3. **Check if it's already done.** Run `git log --grep=''` and read the related commits. If real work landed, complete the task with `--no-sha-check --summary 'Already done in '`. 4. **Make sure your changes don't regress recent functionality.** Many agents have been working on this codebase. Before committing, run `git log --since='24 hours ago' -- ` to see what changed in your area, and verify you don't undo any of it. 5. **Stay scoped.** Only do what this specific task asks for. Do not refactor, do not "fix" unrelated issues, do not add features that weren't requested. Scope creep at this point is regression risk. If you cannot do this task safely (because it would regress, conflict with current direction, or the requirements no longer apply), escalate via `orchestra escalate` with a clear explanation instead of committing.

Git Commits (2)

analysis_id = (h.get("analysis_id") or "").strip()
source_analysis_url = f"/analysis/{html.escape(analysis_id)}" if analysis_id else ""

{
  "requirements": {
    "coding": 7,
    "reasoning": 7,
    "analysis": 8
  },
  "_reset_note": "This task was reset after a database incident on 2026-04-17.\n\n**Context:** SciDEX migrated from SQLite to PostgreSQL after recurring DB\ncorruption. Some work done during Apr 16-17 may have been lost.\n\n**Before starting work:**\n1. Check if the task's goal is ALREADY satisfied (run the relevant checks)\n2. Check `git log --all --grep=task:YOUR_TASK_ID` for prior commits\n3. If complete, verify and mark done. If partial, continue. If not done, proceed.\n\n**DB change:** SciDEX now uses PostgreSQL. `get_db()` auto-detects via\nSCIDEX_DB_BACKEND=postgres env var.",
  "_reset_at": "2026-04-18T06:29:22.046013+00:00",
  "_reset_from_status": "done"
}