feat(diagram-views): complete saved-layout update contract - #723
feat(diagram-views): complete saved-layout update contract#723seonghobae wants to merge 23 commits into
Conversation
|
Warning Review limit reached
Next review available in: 9 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthrough다이어그램 뷰의 타입과 CRUD API를 추가했습니다. 백엔드는 편집자 권한, 404 응답, 512KB 레이아웃 제한을 적용합니다. 프론트엔드는 실제 HTTP 모드와 데모 메모리 모드를 지원합니다. 양쪽 동작을 테스트로 검증합니다. Changes다이어그램 뷰 CRUD
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant frontend_api as frontend/src/api.ts
participant backend_api as PUT /api/diagram-views/{diagram_view_uuid}
participant database as AsyncSession
Client->>frontend_api: updateDiagramView(name, layout_json)
frontend_api->>backend_api: 인증 PUT 요청 전송
backend_api->>database: 대상 조회 및 변경사항 커밋
database-->>backend_api: 갱신된 뷰 반환
backend_api-->>frontend_api: DiagramView 응답 반환
frontend_api-->>Client: 갱신된 다이어그램 뷰 반환
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Pull request was converted to draft
Pull request was converted to draft
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@opencode-agent @cwl-noema-review Please independently review exact current head |
|
@opencode-agent Please review exact head |
|
@cwl-noema-review Please independently review exact head |
|
@opencode-agent @cwl-noema-review Please independently review exact current head |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
backend/tests/test_api_diagram_views.py (1)
179-200: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win512 KiB 경계를 직접 검증하십시오.
현재 테스트는 600 KiB payload만 거부하는지 확인합니다. 직렬화된 레이아웃이 정확히 512 KiB일 때 허용되고, 1바이트 클 때 413을 반환하는 focused test를 추가하십시오. 이 테스트는 계약값 변경을 검출합니다.
As per coding guidelines, “Add or update focused tests when changing behavior.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/tests/test_api_diagram_views.py` around lines 179 - 200, Extend the focused tests around update_view to cover the 512 KiB boundary using the serialized layout size: verify a payload exactly 512 KiB is accepted, and a payload one byte larger raises HTTPException with status 413. Reuse the existing DiagramViewCreateIn setup and authorization/session mocks, and retain assertions that rejected updates do not mutate or commit the view.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@backend/app/api/diagram_views.py`:
- Around line 150-165: Add an equivalent request-body size limit at the `/api`
router or upstream middleware so oversized JSON payloads are rejected before
`DiagramViewCreateIn` deserialization and before authentication. Configure the
limit using the existing Traefik/Hypercorn or application request-parsing
mechanism, and retain `_bound_layout_size` as the post-parse validation for
accepted requests.
In `@frontend/src/api.ts`:
- Line 283: Update the demo view ID generation at diagram_view_uuid to include a
module-scoped incrementing sequence or other unique generator alongside
Date.now(), ensuring create calls in the same millisecond receive distinct IDs.
Add a regression test that creates two views with the same timestamp and
verifies each view’s update and delete operations target the correct view.
- Around line 331-337: Update the demo view replacement flow around updated and
demoDiagramViewsByProject so the modified view is repositioned according to
descending updated_at order instead of retaining found.index. Remove the view
from its old position, insert the updated view at the front or sort the
collection by updated_at, and add a regression test covering creation of two
views followed by updating the older one and verifying it appears first.
- Around line 285-292: Apply shared validation before mutating
demoDiagramViewsByProject in both demo create and update paths: require name
length 1–200 characters and reject layout_json whose serialized size exceeds 512
KiB, matching the backend contract. Ensure rejected inputs leave the demo store
unchanged, including before the view is constructed or prepended. Add regression
tests covering rejection and unchanged storage for both create and update.
---
Nitpick comments:
In `@backend/tests/test_api_diagram_views.py`:
- Around line 179-200: Extend the focused tests around update_view to cover the
512 KiB boundary using the serialized layout size: verify a payload exactly 512
KiB is accepted, and a payload one byte larger raises HTTPException with status
413. Reuse the existing DiagramViewCreateIn setup and authorization/session
mocks, and retain assertions that rejected updates do not mutate or commit the
view.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 83f6c9fc-2a3c-40e6-bf26-0b218e0bdcc9
📒 Files selected for processing (6)
CHANGELOG.mdbackend/app/api/diagram_views.pybackend/tests/test_api_diagram_views.pyfrontend/src/api.tsfrontend/src/diagramViewsApi.test.tsfrontend/src/types.ts
|
@opencode-agent @cwl-noema-review Please perform a fresh independent review of current head |
What
Completes the in-place saved ERD view contract across backend and frontend API layers.
Backend
Adds an editor-authorized replacement endpoint:
PUT /api/diagram-views/{diagram_view_uuid}It updates the saved name and complete layout payload while preserving the stable opaque
diagram_view_uuidand original creation metadata.Frontend API foundation
Adds typed, CSRF-protected clients for the complete saved-view lifecycle:
The demo mode now implements the same CRUD contract in memory so the product can demonstrate saved-layout workflows without a backend.
Product gap closed
The backend previously supported create, list, read, and delete but not update, and the frontend had no typed client for any saved-view endpoint. Users would otherwise have to create duplicate views whenever they adjusted table positions, zoom, or review-oriented layouts. This PR establishes the contract required for explicit Save, overwrite, and later autosave UI.
Safety and correctness
editormembership for mutations;created_at;updated_atonly after authorization and payload validation;CHANGELOG.mdrecords the commercial saved-view capability.Summary by CodeRabbit
새로운 기능
개선 사항