[SERVER-36026] Replica set member should fail to parse heartbeat response with unknown fields Created: 09/Jul/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | former-quick-wins | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
Replica set members ignore any unknown fields in heartbeat responses. We should check for unknown fields, so that in the future, if we add a field to the heartbeat response, it is not silently ignored on older-version nodes. This would be consistent with heartbeat request parsing, where we error if there is an unknown field. |
| Comments |
| Comment by Siyuan Zhou [ 29/Jul/18 ] |
|
Removing fields will also need more work. I understand the risk of ignoring unknown fields, but I cannot think of a case of internal messages where it caused us a problem to justify the extra complexity. Protobuf also ignores unknown fields.
|
| Comment by Tess Avitabile (Inactive) [ 09/Jul/18 ] |
|
Yes. However, we can use FCV to decide whether to include new fields. And this would ensure we weren't expecting older version nodes to do something with the new field. |
| Comment by Bruce Lucas (Inactive) [ 09/Jul/18 ] |
|
Could this potentially cause unnecessary compatibility problems for mixed version replica sets during upgrade? |