a2aproject / a2aproject/a2a-js
[Bug]: Some optional properties are required
- Ngôn ngữ chính
- TypeScript
- Star
- 613
- Fork
- 169
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 21
Mô tả
### What happened?
The `filename` property of the `Part` interface is clearly documented as optional, yet it's a required property, which doesn't even accept `undefined`. Within the same interface, there's also `metadata`, which is again documented as optional, but it's in fact a required property (although in this case at least it does accept undefined). In fact, according to [the spec for Part,](https://a2a-protocol.org/v1.0.1/specification/#416-part) **ALL** properties should be optional.
There are many other similar cases, for example in the `Message` interface, where `contextId`, `taskId` and `metadata` are all documented as optional, yet required in code.
I'm aware the code is generated from the `a2a.proto` from the spec repo, but that's also the case for the Python SDK, for example, which doesn't have this issue.
On top of that, I don't understand the need to use `Part.content` as a wrapper over the actual content of the part. Why not use `Part.text` / `raw` / etc, as is done in the Python library?
EDIT:
There are also examples of the opposite kind of problem, having properties which should always be required as possibly undefined, like in the case of `TaskArtifactUpdateEvent.artifact`
### Relevant log output
```shell
```
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Hướng dẫn đóng góp
Hướng nghiên cứu
The issue points to the Part and Message interfaces in the generated TypeScript code, likely in a file like src/generated/a2a.ts. Compare the generated types with the a2a.proto specification and the Python SDK implementation to see how optional fields are handled. Check the protobuf generation configuration and the build process. 'Done' means the optional properties in the TypeScript interfaces correctly reflect the spec and accept undefined.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- javascript, typescript
- Lĩnh vực
- api, backend-api-design
- Loại issue
- Lỗi
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức phù hợp với người mới
- 65/100