Fix infinite re-fetch loop in useJailConfigs
The hook was passing an inline onSuccess callback to useListData, which included onSuccess in its internal refresh function's dependency array. This caused refresh to be recreated on each render, which triggered the useEffect, which fired the fetch, which completed and caused a re-render, creating an infinite loop. Wrap onSuccess in useCallback with empty dependencies so it maintains a stable reference across renders. This allows refresh to be stable when its dependencies don't change, breaking the cycle. Add documentation to Refactoring.md explaining the onSuccess stability requirement for useListData callers. Also add tests for useJailConfigs to verify it doesn't trigger infinite refetches with stable onSuccess callback. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
@@ -72,13 +72,8 @@ Supporting documentation you must know and respect:
|
||||
|
||||
Repeat the following cycle for every task. Do not skip steps.
|
||||
|
||||
### Step 1 — Pick a Task
|
||||
|
||||
- Open `tasks.md` and pick the next unfinished task (highest priority first).
|
||||
- Mark the task as **in progress**.
|
||||
- Read the task description thoroughly. Understand the expected outcome before proceeding.
|
||||
|
||||
### Step 2 — Plan Your Steps
|
||||
### Step 1 — Plan Your Steps
|
||||
|
||||
- Break the task into concrete implementation steps.
|
||||
- Identify which files need to be created, modified, or deleted.
|
||||
@@ -86,7 +81,7 @@ Repeat the following cycle for every task. Do not skip steps.
|
||||
- Identify edge cases and error scenarios.
|
||||
- Write down your plan before touching any code.
|
||||
|
||||
### Step 3 — Write Code
|
||||
### Step 2 — Write Code
|
||||
|
||||
- Implement the feature or fix following the plan.
|
||||
- Follow all rules from the relevant development docs:
|
||||
@@ -97,14 +92,14 @@ Repeat the following cycle for every task. Do not skip steps.
|
||||
- Write clean, well-structured, fully typed code.
|
||||
- Keep commits atomic — one logical change per commit.
|
||||
|
||||
### Step 4 — Add Logging
|
||||
### Step 3 — Add Logging
|
||||
|
||||
- Add structured log statements at key points in new or modified code.
|
||||
- Backend: use **structlog** with contextual key-value pairs — never `print()`.
|
||||
- Log at appropriate levels: `info` for operational events, `warning` for recoverable issues, `error` for failures.
|
||||
- Never log sensitive data (passwords, tokens, session IDs).
|
||||
|
||||
### Step 5 — Write Tests
|
||||
### Step 4 — Write Tests
|
||||
|
||||
- Write tests for every new or changed piece of functionality.
|
||||
- Backend: use `pytest` + `pytest-asyncio` + `httpx.AsyncClient`. See [Backend-Development.md § 9](Backend-Development.md).
|
||||
@@ -113,24 +108,24 @@ Repeat the following cycle for every task. Do not skip steps.
|
||||
- Mock external dependencies — tests must never touch real infrastructure.
|
||||
- Follow the naming pattern: `test_<unit>_<scenario>_<expected>`.
|
||||
|
||||
### Step 6 — Review Your Code
|
||||
### Step 5 — Review Your Code
|
||||
|
||||
Run a thorough self-review before considering the task done. Check **all** of the following:
|
||||
|
||||
#### 6.1 — Warnings and Errors
|
||||
#### 5.1 — Warnings and Errors
|
||||
|
||||
- Backend: run `ruff check` and `mypy --strict` (or `pyright --strict`). Fix every warning and error.
|
||||
- Frontend: run `tsc --noEmit` and `eslint`. Fix every warning and error.
|
||||
- Zero warnings, zero errors — no exceptions.
|
||||
|
||||
#### 6.2 — Test Coverage
|
||||
#### 5.2 — Test Coverage
|
||||
|
||||
- Run the test suite with coverage enabled.
|
||||
- Aim for **>80 % line coverage** overall.
|
||||
- Critical paths (auth, banning, scheduling, API endpoints) must be **100 %** covered.
|
||||
- If coverage is below the threshold, write additional tests before proceeding.
|
||||
|
||||
#### 6.3 — Coding Principles
|
||||
#### 5.3 — Coding Principles
|
||||
|
||||
Verify your code against the coding principles defined in [Backend-Development.md § 13](Backend-Development.md) and [Web-Development.md](Web-Development.md):
|
||||
|
||||
@@ -141,7 +136,7 @@ Verify your code against the coding principles defined in [Backend-Development.m
|
||||
- [ ] **KISS** — The simplest correct solution is used. No over-engineering.
|
||||
- [ ] **Type Safety** — All types are explicit. No `any` / `Any`. No `# type: ignore` without justification.
|
||||
|
||||
#### 6.4 — Architecture Compliance
|
||||
#### 5.4 — Architecture Compliance
|
||||
|
||||
Verify against [Architekture.md](Architekture.md) and the project structure rules:
|
||||
|
||||
@@ -153,7 +148,7 @@ Verify against [Architekture.md](Architekture.md) and the project structure rule
|
||||
- [ ] Pydantic models separate request, response, and domain shapes.
|
||||
- [ ] Frontend types live in `types/`, not scattered across components.
|
||||
|
||||
### Step 7 — Update Documentation
|
||||
### Step 6 — Update Documentation
|
||||
|
||||
- If your change introduces new features, new endpoints, new components, or changes existing behaviour, update the relevant docs:
|
||||
- [Features.md](Features.md) — if feature behaviour changed.
|
||||
@@ -161,51 +156,6 @@ Verify against [Architekture.md](Architekture.md) and the project structure rule
|
||||
- [Backend-Development.md](Backend-Development.md) or [Web-Development.md](Web-Development.md) — if new conventions were established.
|
||||
- Keep documentation accurate and in sync with the code. Outdated docs are worse than no docs.
|
||||
|
||||
### Step 8 — Mark Task Complete
|
||||
|
||||
- Open `tasks.md` and mark the task as **done**.
|
||||
- Add a brief summary of what was implemented or changed.
|
||||
|
||||
### Step 9 — Commit
|
||||
|
||||
- Stage all changed files.
|
||||
- Write a commit message in **imperative tense**, max 72 characters for the subject line.
|
||||
- Good: `Add jail reload endpoint`
|
||||
- Bad: `added stuff` / `WIP` / `fix`
|
||||
- If the change is large, include a body explaining **why**, not just **what**.
|
||||
- Branch naming: `feature/<short-description>`, `fix/<short-description>`, `chore/<short-description>`.
|
||||
- Ensure the commit passes: linter, type checker, all tests.
|
||||
|
||||
### Step 10 — Next Task
|
||||
|
||||
- Return to **Step 1** and pick the next task.
|
||||
|
||||
---
|
||||
|
||||
## 4. Workflow Summary
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ 1. Pick task from tasks.md │
|
||||
│ 2. Plan your steps │
|
||||
│ 3. Write code │
|
||||
│ 4. Add logging │
|
||||
│ 5. Write tests │
|
||||
│ 6. Review your code │
|
||||
│ ├── 6.1 Check warnings & errors │
|
||||
│ ├── 6.2 Check test coverage │
|
||||
│ ├── 6.3 Check coding principles │
|
||||
│ └── 6.4 Check architecture │
|
||||
│ 7. Update documentation if needed │
|
||||
│ 8. Mark task complete in tasks.md │
|
||||
│ 9. Git commit │
|
||||
│ 10. Pick next task ──────── loop ───┐ │
|
||||
│ ▲ │ │
|
||||
│ └───────────────────────────┘ │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. When You Are Stuck
|
||||
|
||||
|
||||
Reference in New Issue
Block a user