google / google/go-dap

Represent optional JSON boolean as `*bool` in Go to avoid altering messages when deserializing and re-serializing

Open
#87 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
140
Forks
29
PR merge metrics
No merged PRs in 30d

Description

Currently, go-dap reprents JSON booleans as `bool`, regardless of whether they are optional or required. As a result, a message that does not set a boolean will have it set to `false` when deserialized and then re-serialized.

Unfortunately, it is not always specified in the DAP protocol how to treat a missing boolean field. Take for example https://microsoft.github.io/debug-adapter-protocol/specification#message:
```
/**
* If true show user.
*/
showUser?: boolean;
```

Strictly speaking (because it is not "Iff" aka "if and only if"), this comment does not specify what should happen when this is unset. And sure enough VS Code interprets missing as true for this field:
https://github.com/microsoft/vscode/blob/27a0cbb26647670ad719bcb47e2d1ca4cee133bf/src/vs/workbench/contrib/debug/browser/debugService.ts#L631

We are deserializing and serializing all messages in a proxy for logging and sanitization, so go-dap turning unset into false is a problem for us.

This could be fixed by representing optional booleans as `*bool` (and then using `omitempty`), similar to how we represent optional nested messages as `*struct`. Unfortunately this is a breaking change as users of the library would then need to dereference the pointer as they read and assign, and handle the nil case explicitly. However, I think this is the correct handling.

What do you think?

Contributor guide

Open the contributing guide

Research direction

The issue names no files or tests; start by reviewing go-dap's message definitions and the proxy serialization path described in the report. Identify optional boolean fields that need pointer representations, verify that missing values survive deserialization and re-serialization, and account for the breaking API change.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend-api-design
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.