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

2018 Fantasy Football API Update #615

Merged
merged 17 commits into from
Jan 7, 2025

Conversation

Robert-litts
Copy link
Contributor

Took another look at the code and made a second attempt to fix #514. The issue is caused by lines 48-51 in espn_requests.py, where the endpoint used for 2018 league in my case should be the older endpoint. When that endpoint is used, the data returned has a 0 index and needs to be handled appropriately. Updates made in base_league.py to handle the 0 index JSON data. Additionally, created a new function in epsn_requests.py to validate if endpoint causes a 401 and if so, try the other endpoint, raise an error if both fail.

@Robert-litts
Copy link
Contributor Author

This also addresses my issue #278.

@Robert-litts
Copy link
Contributor Author

Made the changes & tested it against my previously failing 2018 league. Updates worked for all league years (2017 and prior, 2018, and 2019 and newer). Thanks for the suggestion on where to add this check into the code, and hope the changes make sense.

@Robert-litts
Copy link
Contributor Author

Robert-litts commented Jan 2, 2025

I saw the original tests failed because of the urllib3 version issue. I reran the tests for this PR after you updated/pinned that version earlier today and got the same errors on the test cases that came thru on the next github actions workflow. From my review so far, it looks like because of where I implemented the "check_league_endpoint" function within the class init it is being missed by the test cases.

Taking another look tonight and I'm reconsidering the implementation I initially had with a separate function. This might be more appropriate to place this logic within your existing checkRequestStatus function, which is already being run in both get/league_get.

@Robert-litts
Copy link
Contributor Author

Robert-litts commented Jan 3, 2025

OK, hopefully fourth time is a charm!

  • Moved the alternate endpoint code/logic into checkRequestStatus function & slightly modified the league_get to handle the potential for an alternate endpoint.

  • Did some testing with my original 2018 league that was causing issues and all seems to be working great.
    -- Ran all nosetests in my dev container & all passed except for:

def test_private_league(self):
        with self.assertRaises(Exception):
            League(368876, 2018)

It looks like this test is expecting an exception to be raised, but manually running additional tests with that LeagueID works fine w/o cookies (seems like I don't need cookies for my own league, 747376, either). Was there something else this test was checking for?

Copy link
Owner

@cwendt94 cwendt94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this! I think its really close!

@@ -17,19 +17,49 @@ class ESPNUnknownError(Exception):
pass


def checkRequestStatus(status: int, cookies=None, league_id=None) -> None:
def checkRequestStatus(status: int, cookies=None, league_id=None, league_endpoint=None, year=None, extend="", params=None, headers=None) -> tuple:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make this function a little simpler, I think moving this inside the request class so then you won't have to pass all these fields to it. You then can access all of them through this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I was actually considering that last night, but wasn't sure if you had a reason it was defined outside the class. Moving it inside would definitely simplify access to those params for sure.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah no issues moving it in!

@Robert-litts
Copy link
Contributor Author

Excellent -- I was experimenting with both your League(368876, 2018) and my League(747376, 2018) this morning and it seems like both of those are accessible at the 'leagueHistory' endpoint. So in your test_private_league, it will now not raise an exception with this code, causing the test to fail. At least I think that is what is happening, are you able to validate that assumption?

@cwendt94
Copy link
Owner

cwendt94 commented Jan 3, 2025

Excellent -- I was experimenting with both your League(368876, 2018) and my League(747376, 2018) this morning and it seems like both of those are accessible at the 'leagueHistory' endpoint. So in your test_private_league, it will now not raise an exception with this code, causing the test to fail. At least I think that is what is happening, are you able to validate that assumption?

Wow is it really? Thats an old private league of mine and wouldn't think it would be accessible. I wonder if we update to an older year it would throw?

@Robert-litts
Copy link
Contributor Author

Excellent -- I was experimenting with both your League(368876, 2018) and my League(747376, 2018) this morning and it seems like both of those are accessible at the 'leagueHistory' endpoint. So in your test_private_league, it will now not raise an exception with this code, causing the test to fail. At least I think that is what is happening, are you able to validate that assumption?

Wow is it really? Thats an old private league of mine and wouldn't think it would be accessible. I wonder if we update to an older year it would throw?

Yeah my league is private too and I can access yours and mine without cookies, for all of the older years (mine goes back to 2013). However, I know this original issue was sporadic on some leagues, so I'm hesitant to say that a simple change to make the endpoint for 2018 always use the older URL would work for everyone.

@cwendt94
Copy link
Owner

cwendt94 commented Jan 3, 2025

Excellent -- I was experimenting with both your League(368876, 2018) and my League(747376, 2018) this morning and it seems like both of those are accessible at the 'leagueHistory' endpoint. So in your test_private_league, it will now not raise an exception with this code, causing the test to fail. At least I think that is what is happening, are you able to validate that assumption?

Wow is it really? Thats an old private league of mine and wouldn't think it would be accessible. I wonder if we update to an older year it would throw?

Yeah my league is private too and I can access yours and mine without cookies, for all of the older years (mine goes back to 2013). However, I know this original issue was sporadic on some leagues, so I'm hesitant to say that a simple change to make the endpoint for 2018 always use the older URL would work for everyone.

Nice, well thats a little added feature. Definitely a weird bug on ESPN's side but glad you found a fix for it!

@Robert-litts
Copy link
Contributor Author

Ok I moved the checkRequestStatus function into the class. Everything seems to be working on my end & ran all the tests, and it is still failing just the one I referenced above for your 2018 private league.

How do you want me to handle that one test case failure? I'm not sure how to test that private league feature now since it doesn't appear to be a restriction w/ the data I have.

@cwendt94
Copy link
Owner

cwendt94 commented Jan 6, 2025

How do you want me to handle that one test case failure? I'm not sure how to test that private league feature now since it doesn't appear to be a restriction w/ the data I have.

I think we can use that test to get coverage on the switching endpoint logic. It can be updated to not throw error on private league.

Copy link

codecov bot commented Jan 7, 2025

Codecov Report

Attention: Patch coverage is 86.36364% with 3 lines in your changes missing coverage. Please review.

Project coverage is 83.13%. Comparing base (895ec28) to head (a717848).
Report is 18 commits behind head on master.

Files with missing lines Patch % Lines
espn_api/requests/espn_requests.py 86.36% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #615      +/-   ##
==========================================
- Coverage   83.21%   83.13%   -0.09%     
==========================================
  Files          61       61              
  Lines        2300     2306       +6     
==========================================
+ Hits         1914     1917       +3     
- Misses        386      389       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Robert-litts
Copy link
Contributor Author

Robert-litts commented Jan 7, 2025

How do you want me to handle that one test case failure? I'm not sure how to test that private league feature now since it doesn't appear to be a restriction w/ the data I have.

I think we can use that test to get coverage on the switching endpoint logic. It can be updated to not throw error on private league.

I modified the test_private_league to validate the LEAGUE_ENDPOINT URL it switches to (i.e. it falls back to the /leagueHistory/ endpoint), since per the code a year=2018 request would normally use the /seasons/ endpoint. I added random, invalid credentials to ensure it fails & falls back to the leagueHistory endpoint (but it should switch even without those creds).

I re-read your comment and now realize you had said the test could check that it does not throw an error for a private league. I can modify back to that if you'd prefer or just add that back as an additional test case if you see value in the one I modified here.

Interesting side-note, it appears the /leagueHistory/ no longer requires credentials -- I did some testing on some randomly generated league numbers and it looks like it succeeds every time.

@cwendt94
Copy link
Owner

cwendt94 commented Jan 7, 2025

Interesting side-note, it appears the /leagueHistory/ no longer requires credentials -- I did some testing on some randomly generated league numbers and it looks like it succeeds every time.

This looks good! Interesting, thats kind of nice!

@cwendt94 cwendt94 merged commit 107cc52 into cwendt94:master Jan 7, 2025
3 checks passed
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 this pull request may close these issues.

2 participants