Cannot read properties of `null` (reading 'id')

[grrowl]

› linearis issues read BRA-71
{
  "error": "Cannot read properties of null (reading 'id')"
}

the issue id exists; i note list shows identifier not id. Looking up an ID which doesn't exist outputs a much better error message.

› linearis issues read BRA-713
{
  "error": "Issue with identifier \"BRA-713\" not found"
}

[czottmann]

Thanks for the report, @grrowl. Help me understand this better, please.

In your Linear instance, the identifier "BRA-71" does indeed exist but the error says that linearis tried to use "BRA-71" as the id parameter, is that correct?

[abaileyb]

experiencing this same issue :(

[chorn21]

Also experiencing this issue with linearis issues read and linearis issues update. The update task seems to still perform the update, though.

[trounceabout]

+1 to this issue.

And yeah @czottmann, in my case the Issue does exist. It even shows up in the list when I use linearis issues list.

[czottmann]

Thanks. To be honest, the error isn't very telling. Some field was not set and its id prop couldn't be read. It's likely that some nested property wasn't what we expected. Instead of hammering away at symptoms, I'll add some better error reporting to upcoming version 2025.12.1.

That doesn't help in the short run but if/when you come across this issue again, we'll learn about the cause, not just a symptom.

[czottmann]

@trounceabout @grrowl @chorn21 @abaileyb New Linearis version is out, with better error reporting, if you come across the issue again, please add the errors to this here ticket – TIA!

[linuz90]

Encountered this issue with linearis issues read TYP-5506.

The debug output revealed the root cause: a comment with user: null (a system-generated Slack sync notification):

{
  "id": "481b5b53-4529-4ceb-a1c7-364385fcb32d",
  "body": "This comment thread is synced to a corresponding [thread in Slack]...",
  "createdAt": "2025-06-27T06:20:25.655Z",
  "user": null  // <-- This causes the crash
}

The error occurs in graphql-issues-service.js:577 at doTransformIssueData when mapping comments and trying to access user.id without a null check.

The fix would be to handle user: null gracefully in the comment transformation (e.g., show "System" or skip the user field).

[rbolkey]

@czottmann I've encountered this same issue ... added PR #38 for your review

[iamfj]

Hey everyone, thanks for tracking this down — especially @linuz90 for pinpointing the user: null cause on system-generated comments.

Big thanks to @rbolkey (#38) and @AaronPlave (#35) for jumping in with fixes — really appreciate you both taking the time to contribute PRs. That kind of initiative from the community is what makes open source great.

This should be fixed in the upcoming release. On the next branch (see #45), we've replaced the manual type definitions and data transformation layer with GraphQL codegen. The old doTransformIssueData code path that crashed on user: null no longer exists — issue and comment data is now returned directly from the typed GraphQL response without manual property mapping, so null fields are handled naturally.

Feel free to give the next branch a spin if you'd like to verify early.