Fix document deletion persistence issue (#278)#289
Merged
Conversation
- Fixed projectService methods to include project_id parameter in API calls
- Updated deleteDocument() to use correct endpoint: /api/projects/{projectId}/docs/{docId}
- Updated getDocument() and updateDocument() to use correct endpoints with project_id
- Modified DocsTab component to call backend API when deleting documents
- Documents now properly persist deletion after page refresh
The issue was that document deletion was only happening in UI state and never
reached the backend. The service methods were using incorrect API endpoints
that didn't include the required project_id parameter.
- Add Document interface for type safety - Fix error messages to include projectId context - Add unit tests for all projectService document methods - Add integration tests for DocsTab deletion flow - Update vitest config to include new test files
Collaborator
Author
|
solves: #278 |
Owner
|
Thanks @Wirasm !! |
POWERFULMOVES
added a commit
to POWERFULMOVES/PMOVES-Archon
that referenced
this pull request
Feb 12, 2026
coleam00
pushed a commit
that referenced
this pull request
Apr 7, 2026
Command loading was failing for commands in .archon/commands/defaults/ because getCommandFolderSearchPaths() only searched .archon/commands/ directly. This was inconsistent with the workflow loader which searches subdirectories recursively. The fix adds .archon/commands/defaults to the search paths, maintaining priority order: user commands first, then bundled defaults. Fixes #282
Tyone88
pushed a commit
to Tyone88/Archon
that referenced
this pull request
Apr 16, 2026
Command loading was failing for commands in .archon/commands/defaults/ because getCommandFolderSearchPaths() only searched .archon/commands/ directly. This was inconsistent with the workflow loader which searches subdirectories recursively. The fix adds .archon/commands/defaults to the search paths, maintaining priority order: user commands first, then bundled defaults. Fixes coleam00#282
joaobmonteiro
pushed a commit
to joaobmonteiro/Archon
that referenced
this pull request
Apr 26, 2026
Command loading was failing for commands in .archon/commands/defaults/ because getCommandFolderSearchPaths() only searched .archon/commands/ directly. This was inconsistent with the workflow loader which searches subdirectories recursively. The fix adds .archon/commands/defaults to the search paths, maintaining priority order: user commands first, then bundled defaults. Fixes coleam00#282
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Summary
Fixes issue #278 where document deletions were not persisting to the backend database. The UI would show documents as deleted, but they would reappear after page refresh.
Changes Made
Type of Change
Affected Services
Testing
Test Evidence
Checklist
Breaking Changes
None - this is a bug fix that maintains backward compatibility.
Additional Notes
Root cause was that the document deletion API calls were missing the project_id parameter in the URL path, causing 404 errors that were silently caught. The frontend state would update optimistically but the backend never received the delete request.
This fix ensures that: