Release/v3.3.0 - #47
Conversation
Backend: - Added data export API endpoints to download readings, alerts, and anomalies in CSV format. - Expanded the pytest test suite to 41 passing tests. Frontend: - Integrated fleet management API (registration modal, status indicators, and deletion). - Added CSV export functionality across the dashboard, alerts, and anomalies pages. Firmware (C/C++): - Implemented EvidenceStore utilizing a circular buffer to preserve up to 32 EvidenceSnapshot records. - Added FNV-1a hash chain verification to ensure data integrity and enable tamper detection. - Introduced 8 new unit tests for the evidence preservation logic. CI & Documentation: - Added 'backend-test' job (Python 3.11, pytest) to the CI pipeline, bringing the total to 7 jobs. - Updated ROADMAP.md and CHANGELOG.md to reflect v3.2.0 completion. Closes #33 Refs #44
…implement backend notification engine, and introduce new frontend entry point with updated documentation.
…ure across the firmware, backend, and frontend.
…oadmap, architecture, and tech stack guides
…, requirements, and security audit
…re test suite, FastAPI backend schemas, and dashboard components
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1de6ba10b2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| power_mw = Column(Integer, default=0) | ||
| power_factor = Column(Integer, default=0) | ||
| phase = Column(Integer, default=0) | ||
| temperature_c = Column(Float, nullable=True) |
There was a problem hiding this comment.
Add migration for new meter_readings columns
Adding new meter_readings fields here breaks upgrades that keep an existing gridshield.db: SQLAlchemy create_all does not ALTER existing tables, so older databases will still lack these columns and ORM reads/writes can fail at runtime with no such column errors. This impacts core paths like /api/meter-data and /api/readings after deployment unless a schema migration (or explicit compatibility handling) is added.
Useful? React with 👍 / 👎.
|
|
||
| /** Reset all data (readings, alerts, anomalies, notifications) */ | ||
| export function resetAllData() { | ||
| return fetch(`${BASE}/reset`, { method: 'DELETE' }).then(r => r.json()); |
There was a problem hiding this comment.
Throw on failed reset responses in API client
This bypasses the shared request() error handling and always parses JSON, so 4xx/5xx responses from /api/reset are treated as success by callers. In the dashboard reset flow, that means users can see a successful reset message and forced reload even when the backend reset failed. Use request('/reset', { method: 'DELETE' }) or explicitly reject when r.ok is false.
Useful? React with 👍 / 👎.
|
@copilot resolve the merge conflicts in this pull request |
Co-authored-by: zuudevs <[email protected]>
Resolved all merge conflicts with
|
No description provided.