Skip to content
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

Search no longer works on Mastodon < 2.8.0 #167

Closed
jfmcbrayer opened this issue May 7, 2019 · 9 comments
Closed

Search no longer works on Mastodon < 2.8.0 #167

jfmcbrayer opened this issue May 7, 2019 · 9 comments

Comments

@jfmcbrayer
Copy link
Contributor

The required version for mastodon.search() and mastodon.search_v2() were bumped to 2.8.0, probably because 2.8.0 added paging parameters. However, it should still be possible to search without paging on Mastodon < 2.8.0, as it was before.

This is causing https://github.com/jfmcbrayer/brutaldon/issues/63.

@halcy
Copy link
Owner

halcy commented May 7, 2019

Oh bother, yeah, it should not be broken. I did change search to use search_v2 by default, but that should still work on older (though not TOO old) versions. Maybe it should select what function to use dynamically based on if v2 is available anyways.

I'll look into it.

@jfmcbrayer
Copy link
Contributor Author

Looking at the documentation, it looks like search_v2 should be for 2.4.1 and later.

The additional parameters type, limit, offset, min_id, max_id, and account_id were added in 2.8.0, but are still not documented in the official API documentation, only in the pull request here: mastodon/mastodon#10091

Arguably, it would be better to support search_v2 for 2.4.1 and later, but push the additional parameters to a separate function that's only available for 2.8.0 and later.

@halcy
Copy link
Owner

halcy commented May 8, 2019

I'd prefer not having ANOTHER separate version, so maybe the following would be good:

  1. If < 2.4.1, search uses search_v1, otherwise v2

  2. If < 2.8.0 and pagination parameters are passed, a meaningful error is thrown client-side that you can catch and that is documented. If they are not passed, they are not sent automatically. This is probably what should have happened to begin with.

Does that sound good to you from an application perspective?

@jfmcbrayer
Copy link
Contributor Author

Yeah, that's totally reasonable.

@halcy
Copy link
Owner

halcy commented May 8, 2019

Fixed in 8675b25

@halcy halcy closed this as completed May 8, 2019
@halcy
Copy link
Owner

halcy commented May 8, 2019

Unsure why the comments are out of order. Fixed in 8675b25

@jfmcbrayer
Copy link
Contributor Author

Thanks for the fast fix; this probably merits a release in order to fix broken clients. (Selfishly, I want this to fix brutaldon).

@halcy
Copy link
Owner

halcy commented May 9, 2019

yeah, will absolutely do a release, I just want to also get full 2.8.2 support in and re-run the unit tests. Will likely do all of that after I get home from work, I already got blurhash decoding working yesterday, so expect 1.4.1 in maybe 10 to 12 hours from now.

@halcy
Copy link
Owner

halcy commented May 9, 2019

well, might unfortunately not quite make it today, but tomorrow, I'll definitely get this done.

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

No branches or pull requests

2 participants