Property write endpoints acknowledge mutations they never perform: POST/PUT/DELETE only invalidate the cache

[nanaf6203-bit]

Property write endpoints acknowledge mutations they never perform: POST/PUT/DELETE only invalidate the cache

Labels / Complexity: Frontend · Medium Complexity — Medium

Problem

src/app/api/properties/route.ts (POST) and src/app/api/properties/[id]/route.ts (PUT, DELETE) respond with success messages without persisting anything:

// POST /api/properties
// Here you would normally save the property to your database/blockchain
// For now, we'll just invalidate the cache
await redisCacheService.invalidateAllProperties();
return NextResponse.json({ message: 'Property created/updated successfully', cacheInvalidated: true });

The PUT and DELETE handlers carry the identical pattern ("Here you would normally update/delete the property in your database/blockchain" / "For now, we'll just invalidate the cache"). Any client or integrator that calls these endpoints — including the app's own forms — receives a 200 with "successfully" and the property is neither created, updated, nor deleted; only the cache is dropped. Because the write is a no-op, the response is indistinguishable from a real write, so the failure mode is silent: data loss for anyone who trusts the response. The handlers are CSRF-protected but not authenticated, compounding the trap (anyone with a CSRF token can trigger cache invalidation).

Root cause

src/app/api/properties/route.ts line ~100 and src/app/api/properties/[id]/route.ts lines ~92 and ~130: success responses returned after cache invalidation only, with the "you would normally" comment marking the missing persistence.

Why this is architecturally hard

1. The endpoints need a real write target. Property creation/update/delete must go to a backend or chain; with no write target existing, the contributor must define the contract (which fields, ownership rules, id assignment) — a cross-repo decision if the PropChain-BackEnd API is the target.
2. Cache invalidation is entangled with the fake write. The current code invalidates cache instead of writing; a correct fix must invalidate after a successful write, and ordering bugs here cause stale listings to persist.
3. Authentication must be added, not assumed. These are state-changing routes with CSRF-only protection; the fix must decide who may create/delete properties and enforce it.

Downstream impact

Any form or integrator calling these routes (the app's own property forms, and any external client) currently believes writes succeed. The fix changes response semantics from "cache invalidated" to real success/failure, so consumers must handle error statuses they never see today.

Acceptance criteria

• POST, PUT, and DELETE on the property routes perform a real write (create/update/delete) against the chosen backend or return a documented 501/error — never a success response for a no-op.
• Cache invalidation happens only after a successful write.
• State-changing routes require authentication; an unauthenticated write is rejected with a test.
• The "you would normally" comments are removed; the implementation matches the documented behavior.

Out of scope

Building the property-creation UI flow.

Getting started

Files: src/app/api/properties/route.ts, src/app/api/properties/[id]/route.ts. Commands: npm run lint, npm test. Good first files to read: src/app/api/properties/route.ts, src/lib/propertyService.ts.