-
Current Behavior
- UI calls backend to validate repository / resolve default branch
- Backend delegates to Sztabina (
/repos/default-branch-by-url) - Sztabina returns specific failure reasons (e.g. “only HTTPS URLs are supported”)
- Backend collapses this into a generic error
- UI displays a generic, sometimes incorrect message
Example:
- Input:
http://tigase.dev/sztab - Actual failure: Sztabina rejects non-HTTPS URLs
- UI message: “Invalid Git repository or credentials: Failed to resolve default branch”
Expected Behavior
- Backend should preserve and propagate Sztabina error messages (or structured error codes)
- UI should display the specific error returned by Sztabina
- Users should see actionable feedback (e.g. “Only HTTPS Git URLs are supported”)
Impact
- Confusing and misleading UX during project creation
- Users may assume credential or repository issues when the problem is URL scheme
- Increases trial-and-error and support burden
Reproduction Steps
- Open “Create Project” dialog
- Enter a Git repository URL using
http://(nothttps://) - Provide valid username and PAT
- Click “Validate repository”
Actual Result
Generic error message shown:
Invalid Git repository or credentials: Failed to resolve default branch
Expected Result
Specific error message shown:
Only HTTPS Git URLs are supported
Priority
Low–Medium (post-release polish)
| Type |
Bug
|
| Priority |
Major
|
| Assignee | |
| Version |
1.0
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue Votes (0)
Git operations (clone, push, pull, branch creation) that fail in Sztabina currently surface as generic "Failed to..." messages in the UI. The specific error from Sztabina is lost at the Spring Boot boundary.
Sztabina error responses should be propagated through Spring Boot to the frontend with enough context for the user to take corrective action.
Examples: