import_issues
Operational diagnostics log for import problems
SQL
Support
Diagnostics
import_issues
Purpose
Stores diagnostic records when army import parsing or commit logic encounters unmatched units, resolution failures, or commit-level errors. This is a support and debugging table, not a core gameplay table.
Columns
| Column | Type | Null | Notes |
|---|---|---|---|
id | bigint unsigned | No | Primary key |
user_id | bigint unsigned | No | User who triggered the import |
source_format | varchar(50) | No | OWB / NR / SIC etc. |
system | varchar(50) | Yes | Game system text |
list_name | varchar(200) | Yes | Imported list name snapshot |
race_text | varchar(200) | Yes | Race text seen during import |
faction_text | varchar(200) | Yes | Faction text seen during import |
unit_name | varchar(200) | Yes | Problematic unit name |
unit_type | varchar(50) | Yes | Problematic unit type |
qty | int | Yes | Parsed quantity snapshot |
points | int | Yes | Parsed points snapshot |
error_code | varchar(80) | No | Compact issue classifier |
error_detail | varchar(255) | Yes | Short detail text |
created_at | datetime | No | Creation timestamp |
Keys and indexes
PRIMARY KEY (id)KEY idx_import_issues_user (user_id)KEY idx_import_issues_created (created_at)KEY idx_import_issues_error (error_code)
Foreign keys
fk_import_issues_user: import_issues.user_id → users.id ON DELETE CASCADE
Used by
- OWB import commit endpoint
- New Recruit import commit endpoint
- 2nd in Command import commit endpoint
- Import debug/support analysis
Design notes
- This is intentionally a lightweight operational log table
- It stores contextual snapshots rather than only a raw stack/error blob
- It is designed for supportability, not strict normalization
- No delete/retention strategy is visible in schema
Why this table matters
Import reliability is one of the main complexity points in BattleScore. This table provides the evidence trail needed to debug bad roster text, unresolved units, and schema/content mismatches without relying solely on ephemeral logs.
Risks
- Can grow indefinitely without retention rules
- Only stores short detail text, so very deep diagnostics may still require server logs
- Operational usefulness depends on disciplined error-code usage in application logic
Recommended future improvements
- Add retention or archival policy
- Standardise
error_codetaxonomy centrally - Consider linking to richer debug payloads if import complexity grows further