Skip to content

ProposalService error handler crashes when Axios error has no response #8915

Description

@Kumar-s75

Steps to reproduce

  1. Open Calendar and navigate to meeting proposals.
  2. Disable the network in browser developer tools.
  3. Try to list, create, update, delete, convert, or respond to a proposal.
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions