Steps to reproduce
- Open Calendar and navigate to meeting proposals.
- Disable the network in browser developer tools.
- Try to list, create, update, delete, convert, or respond to a proposal.
- Inspect the resulting error or browser console.
Expected behavior
ProposalService should handle a request-level/network failure, log useful information, and preserve the original Axios error as the cause.
Actual behavior
The error handler can throw a secondary TypeError, masking the actual network failure:
TypeError: Cannot read properties of undefined (reading 'headers')
Calendar app version
6.7.0-dev.1 (main at commit 6dcc3a746)
CalDAV-clients used
Not applicable
Browser
Any browser when the proposal request fails before receiving an HTTP response
Client operating system
Not applicable
Server operating system
Not applicable
Web server
Not applicable
Database engine version
Not applicable
PHP engine version
Not applicable
Nextcloud version
Development version compatible with Calendar main
Updated from an older installed version or fresh install
Not applicable
List of activated apps
Not applicable
Nextcloud configuration
Not applicable
Web server error log
Not applicable
Log file
Not applicable
Browser log
TypeError: Cannot read properties of undefined (reading 'headers')
Additional info
Cause
The catch block in src/services/proposalService.ts assumes every caught value has an Axios response:
if (error.response.headers['content-type'] && ...) {
// ...
} else {
message = `${error.response.status} ${error.response.statusText}`
}
Axios network, DNS, timeout, cancellation, and some browser-level errors can have no response. A caught value is also unknown, which is why npm run ts:check currently reports multiple TS18046 errors for this block.
Suggested fix
Use axios.isAxiosError(error), check whether error.response exists before reading it, and fall back to error.message or a generic request-failure message. The thrown service error should retain the original error as cause.
Please also add tests for both HTTP-response errors and Axios errors without a response.
Steps to reproduce
Expected behavior
ProposalServiceshould handle a request-level/network failure, log useful information, and preserve the original Axios error as the cause.Actual behavior
The error handler can throw a secondary
TypeError, masking the actual network failure:Calendar app version
6.7.0-dev.1(mainat commit6dcc3a746)CalDAV-clients used
Not applicable
Browser
Any browser when the proposal request fails before receiving an HTTP response
Client operating system
Not applicable
Server operating system
Not applicable
Web server
Not applicable
Database engine version
Not applicable
PHP engine version
Not applicable
Nextcloud version
Development version compatible with Calendar
mainUpdated from an older installed version or fresh install
Not applicable
List of activated apps
Not applicable
Nextcloud configuration
Not applicable
Web server error log
Not applicable
Log file
Not applicable
Browser log
Additional info
Cause
The catch block in
src/services/proposalService.tsassumes every caught value has an Axios response:Axios network, DNS, timeout, cancellation, and some browser-level errors can have no
response. A caught value is alsounknown, which is whynpm run ts:checkcurrently reports multipleTS18046errors for this block.Suggested fix
Use
axios.isAxiosError(error), check whethererror.responseexists before reading it, and fall back toerror.messageor a generic request-failure message. The thrown service error should retain the original error ascause.Please also add tests for both HTTP-response errors and Axios errors without a response.