profile_include_location #170

Open
anomalist wants to merge 0 commits from profile_include_location into master
Owner

Profile Map Loading and Deletion Issues - Resolution Summary

Problem Description

The TimeSafari application experienced two critical issues in the profile management functionality:

1. Map Loading Failure

  • Error: TypeError: Cannot read properties of undefined (reading 'Default')
  • Location: AccountViewView.vue when "Include Location" checkbox was selected
  • Impact: Map component failed to render, showing "Loading map..." indefinitely
  • Root Cause: Leaflet's default icon system not properly initialized in modern bundler environment

2. Profile Deletion Failure

  • Error: "Error deleting profile: Error: Profile not deleted"
  • Location: Profile deletion API endpoint
  • Impact: Users unable to delete profiles despite successful server operations
  • Root Cause: HTTP 204 "No Content" status incorrectly treated as error instead of success

Technical Analysis

Map Loading Issue

The error occurred in the Vue Leaflet component during the mounted lifecycle hook. Leaflet requires proper icon configuration before map rendering, but the default icon assets weren't accessible in the Vite bundler environment.

Profile Deletion Issue

The API was correctly returning HTTP 204 (No Content) for successful DELETE operations, but the client-side code only recognized HTTP 200 as success. HTTP 204 is the standard response for DELETE operations where no content is returned.

Resolution Implementation

Map Loading Fix

  1. Added Full Leaflet Import: import * as L from "leaflet" for complete object access
  2. Implemented Icon Configuration: Fixed default icon URLs in created() lifecycle hook
  3. Added Map State Management: Implemented isMapReady flag with fallback timeouts
  4. Enhanced Error Handling: Added comprehensive try-catch blocks and logging
  5. Improved Component Lifecycle: Added @mounted event handler for reliable initialization

Profile Deletion Fix

  1. Updated Status Code Handling: Accept both HTTP 200 and 204 as success responses
  2. Enhanced Error Logging: Added detailed API request/response logging
  3. Improved User Feedback: Show specific error messages instead of generic failures
  4. Added Status Code Validation: Handle 400, 401, 403, and 404 responses appropriately

Code Changes Summary

Files Modified

  • src/views/AccountViewView.vue - Map component and profile management
  • src/services/ProfileService.ts - API error handling and status code logic

Key Changes

  • Leaflet icon initialization in component lifecycle
  • Map ready state management with fallback mechanisms
  • Enhanced error handling for profile operations
  • HTTP status code validation for DELETE operations
  • Comprehensive logging and debugging throughout

Testing Results

  • Map Loading: Now renders immediately when location checkbox is checked
  • Profile Deletion: Successfully processes HTTP 204 responses
  • Error Handling: Provides clear, actionable error messages
  • User Experience: No more infinite loading states or misleading error messages

Lessons Learned

  1. HTTP Status Codes: 204 "No Content" is valid success for DELETE operations
  2. Leaflet Integration: Modern bundlers require explicit icon configuration
  3. Error Handling: Generic error messages hide real problems; specific logging is essential
  4. Component Lifecycle: Vue component events can be unreliable; fallback mechanisms are necessary

This resolution demonstrates the importance of understanding HTTP semantics and properly configuring third-party libraries in modern JavaScript bundler environments.

# Profile Map Loading and Deletion Issues - Resolution Summary ## Problem Description The TimeSafari application experienced two critical issues in the profile management functionality: ### 1. Map Loading Failure - **Error**: `TypeError: Cannot read properties of undefined (reading 'Default')` - **Location**: AccountViewView.vue when "Include Location" checkbox was selected - **Impact**: Map component failed to render, showing "Loading map..." indefinitely - **Root Cause**: Leaflet's default icon system not properly initialized in modern bundler environment ### 2. Profile Deletion Failure - **Error**: "Error deleting profile: Error: Profile not deleted" - **Location**: Profile deletion API endpoint - **Impact**: Users unable to delete profiles despite successful server operations - **Root Cause**: HTTP 204 "No Content" status incorrectly treated as error instead of success ## Technical Analysis ### Map Loading Issue The error occurred in the Vue Leaflet component during the `mounted` lifecycle hook. Leaflet requires proper icon configuration before map rendering, but the default icon assets weren't accessible in the Vite bundler environment. ### Profile Deletion Issue The API was correctly returning HTTP 204 (No Content) for successful DELETE operations, but the client-side code only recognized HTTP 200 as success. HTTP 204 is the standard response for DELETE operations where no content is returned. ## Resolution Implementation ### Map Loading Fix 1. **Added Full Leaflet Import**: `import * as L from "leaflet"` for complete object access 2. **Implemented Icon Configuration**: Fixed default icon URLs in `created()` lifecycle hook 3. **Added Map State Management**: Implemented `isMapReady` flag with fallback timeouts 4. **Enhanced Error Handling**: Added comprehensive try-catch blocks and logging 5. **Improved Component Lifecycle**: Added `@mounted` event handler for reliable initialization ### Profile Deletion Fix 1. **Updated Status Code Handling**: Accept both HTTP 200 and 204 as success responses 2. **Enhanced Error Logging**: Added detailed API request/response logging 3. **Improved User Feedback**: Show specific error messages instead of generic failures 4. **Added Status Code Validation**: Handle 400, 401, 403, and 404 responses appropriately ## Code Changes Summary ### Files Modified - `src/views/AccountViewView.vue` - Map component and profile management - `src/services/ProfileService.ts` - API error handling and status code logic ### Key Changes - Leaflet icon initialization in component lifecycle - Map ready state management with fallback mechanisms - Enhanced error handling for profile operations - HTTP status code validation for DELETE operations - Comprehensive logging and debugging throughout ## Testing Results - **Map Loading**: ✅ Now renders immediately when location checkbox is checked - **Profile Deletion**: ✅ Successfully processes HTTP 204 responses - **Error Handling**: ✅ Provides clear, actionable error messages - **User Experience**: ✅ No more infinite loading states or misleading error messages ## Lessons Learned 1. **HTTP Status Codes**: 204 "No Content" is valid success for DELETE operations 2. **Leaflet Integration**: Modern bundlers require explicit icon configuration 3. **Error Handling**: Generic error messages hide real problems; specific logging is essential 4. **Component Lifecycle**: Vue component events can be unreliable; fallback mechanisms are necessary This resolution demonstrates the importance of understanding HTTP semantics and properly configuring third-party libraries in modern JavaScript bundler environments.
anomalist added 2 commits 2 months ago
bc9d3cdda5 fix(profile): resolve map loading and profile deletion issues
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 3 commits 2 months ago
a85b508f44 feat: implement enhanced workflow state system with commit override capability
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
fd30343ec4 fix(settings): resolve server switching not applying immediately
anomalist added 1 commit 2 months ago
f0fd8c0f12 feat(diagnostics): add comprehensive logging for server switching and user registration
anomalist added 1 commit 2 months ago
6aac3ca35f fix(api): resolve image server hardcoding and add comprehensive diagnostics
anomalist added 3 commits 2 months ago
271a45afa3 fix(database): resolve ambiguous settings query logic
7f7680f4a6 fix(config): remove forced API server overrides
a11443dc3a feat(logging): enhance diagnostic logging for API operations
anomalist added 1 commit 2 months ago
77a4c60656 fix(ProfileService): revert to working endpoint for profile loading
anomalist added 1 commit 2 months ago
b834596ba6 feat(meta-rules): create change evaluation and breaking change detection rule
trentlarson reviewed 2 months ago
"SELECT * FROM settings WHERE accountDid = ?",
[key],
);
}
Poster
Owner

Definitely! Thanks for catching this... bad interface.

Definitely! Thanks for catching this... bad interface.
trentlarson marked this conversation as resolved
trentlarson reviewed 2 months ago
fallback: Settings | null = null,
): Promise<Settings | null> {
Poster
Owner

So the $getSettings appears to be only called in places that supply the MASTER_SETTINGS_KEY, so there's no need for non-key account-id-oriented logic -- and we could even remove the key and make it $getMasterSettings (even in the $getMergedSettings case).

So the $getSettings appears to be only called in places that supply the MASTER_SETTINGS_KEY, so there's no need for non-key account-id-oriented logic -- and we could even remove the key and make it $getMasterSettings (even in the $getMergedSettings case).
Poster
Owner

This one slipped off my radar during the day. I'll attend to it today.

This one slipped off my radar during the day. I'll attend to it today.
anomalist marked this conversation as resolved
Owner

A couple of observations:

  • A lot of logger.info calls should probably be logger.debug. (FYI I'm seeing this in master, too, like the router on every navigation call.)

  • A permanent "FIXED" comment in the code seems spurious.

A couple of observations: * A lot of logger.info calls should probably be logger.debug. (FYI I'm seeing this in master, too, like the router on every navigation call.) * A permanent "FIXED" comment in the code seems spurious.
Owner

So the fix to the bad server setting (ie. initializing after settings are loaded) is an easy fix. I can potentially see splitting out some code into ProfileService if AccountViewView is getting too large. However, the new service & usage is becoming incredibly complex. I'm guessing there's some vision for something general-purpose, but... A) this is currently only used in exactly one file, and B) this adds some new conventions for registering a service & marking initialized which adds complication and will take some explanation (and I wonder if it's just something AI threw in).

So the fix to the bad server setting (ie. initializing after settings are loaded) is an easy fix. I can potentially see splitting out some code into ProfileService if AccountViewView is getting too large. However, the new service & usage is becoming incredibly complex. I'm guessing there's some vision for something general-purpose, but... A) this is currently only used in exactly one file, and B) this adds some new conventions for registering a service & marking initialized which adds complication and will take some explanation (and I wonder if it's just something AI threw in).
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
9386b2e96f refactor(services): inline ProfileService logic into AccountViewView
anomalist added 1 commit 2 months ago
ceceabf7b5 git commit -m "feat(performance): implement request deduplication for plan loading
anomalist added 1 commit 2 months ago
4f78bfe744 feat: suppress console spam for expected HTTP errors
anomalist added 1 commit 2 months ago
8dab4ed016 feat: suppress console spam for expected HTTP errors in profile operations
trentlarson reviewed 2 months ago
- **Fallback**: Ensure graceful degradation when plugins are unavailable
---
Poster
Owner

Random note: I vote we don't put change-log items in this file, but rather keep it as a summary of the current state of the codebase. That way historical items aren't mixed with modern info. (Heck, just today I had a hard time finding build instructions because it's become so large.)

Random note: I vote we don't put change-log items in this file, but rather keep it as a summary of the current state of the codebase. That way historical items aren't mixed with modern info. (Heck, just today I had a hard time finding build instructions because it's become so large.)
trentlarson marked this conversation as resolved
trentlarson reviewed 2 months ago
const imageResp = await fetchImageRateLimits(
this.axios,
did,
this.DEFAULT_IMAGE_API_SERVER,
Poster
Owner

I vote we remove this. The argument is optional and defaults to the right value; hard-coding this is yet another place to modify if we allow customization.

I vote we remove this. The argument is optional and defaults to the right value; hard-coding this is yet another place to modify if we allow customization.
trentlarson marked this conversation as resolved
trentlarson reviewed 2 months ago
private async ensureCorrectApiServer() {
Poster
Owner

Another random FYI: if there's no problem with Electron setup any more, I don't see any reason for this method. The API server is the one value that is ALWAYS set in the DB.

https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/src/branch/master/src/db-sql/migration.ts#L92

Another random FYI: if there's no problem with Electron setup any more, I don't see any reason for this method. The API server is the one value that is ALWAYS set in the DB. https://gitea.anomalistdesign.com/trent_larson/crowd-funder-for-time-pwa/src/branch/master/src/db-sql/migration.ts#L92
trentlarson marked this conversation as resolved
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
anomalist added 1 commit 2 months ago
98f97f2dc9 refactor(settings): simplify $getSettings to $getMasterSettings
anomalist added 1 commit 2 months ago
Owner

👍

👍
This branch is equal with the target branch.
This branch is out-of-date with the base branch
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.