Skip to content

Breaking change in WatchEvent API introduced in v3.24.0 #2777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rastislavs opened this issue Mar 4, 2024 · 10 comments
Closed

Breaking change in WatchEvent API introduced in v3.24.0 #2777

rastislavs opened this issue Mar 4, 2024 · 10 comments

Comments

@rastislavs
Copy link
Contributor

The v3.24.0 introduced a breaking change in WatchEvent API by the commit aff055b

As of this commit, Path in generated events no longer has Nlri and Pattrs attributes set (they are always nil), and instead NlriBinary and PattrsBinary attributes are set.

Not sure what was the motivation behind this change, but as it changes the behavior of the API, it is breaking for the API consumers.

@rastislavs rastislavs changed the title Breaking change in WatchEvent API inttroduced in v3.24.0 Breaking change in WatchEvent API introduced in v3.24.0 Mar 4, 2024
@fujita
Copy link
Member

fujita commented Mar 4, 2024

Thanks for the report! Sounds like needs to be reverted.

@rastislavs
Copy link
Contributor Author

Right, reverting the changes on the 3 modified lines in BgpServer.WatchEvent should be also sufficient - maybe @bayrinat could tell us what was the intention behind this change?

@fujita
Copy link
Member

fujita commented Mar 4, 2024

The intention is adding EOR support to the EventAPI.

@rastislavs
Copy link
Contributor Author

The intention is adding EOR support to the EventAPI.

Ah, I meant specifically, switching the onlyBinary argument of toPathApi calls in WatchEvent from false to true.

@fujita
Copy link
Member

fujita commented Mar 4, 2024

Oops, understood.

rastislavs added a commit to rastislavs/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
rastislavs added a commit to rastislavs/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
rastislavs added a commit to rastislavs/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
rastislavs added a commit to rastislavs/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
rastislavs added a commit to rastislavs/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
@bayrinat
Copy link
Contributor

bayrinat commented Mar 4, 2024

Hello, my bad. This change wasn't suppose to be there.

@rastislavs Thanks for the quick revert, I'll do the proper change soon.

aanm pushed a commit to cilium/cilium that referenced this issue Mar 4, 2024
Due to a breaking change in GoBGP v3.24.0, do not update GoBGP
until the issue osrg/gobgp#2777
is resolved.

Signed-off-by: Rastislav Szabo <[email protected]>
fujita added a commit to fujita/gobgp that referenced this issue Mar 5, 2024
This reverts commit fbeaa1c.

This breaks WatchEvent API:
osrg#2777
fujita added a commit to fujita/gobgp that referenced this issue Mar 5, 2024
This reverts commit aff055b.

This breaks WatchEvent API:
osrg#2777
@fujita
Copy link
Member

fujita commented Mar 5, 2024

I prefer clean revert:
#2779

@fujita
Copy link
Member

fujita commented Mar 6, 2024

I reverted two commits. The API should work as before.

@rastislavs
Copy link
Contributor Author

Yes, I just tested that on top of the commit 9d05544 everything works as expected. Thank you.

@bayrinat
Copy link
Contributor

The second attempt without breaking changes - #2780

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants