Closed gaelollivier closed 1 year ago
Looking at the code, I suspect the API might be returning a new status that isn’t being handled by CAMPSITE_UNAVAILABLE_STRINGS.
One suggestion I can think of to make this more robust: instead of using a deny list for the list of codes that are considered unavailable, could this be changed to an allow list of codes for available statuses?
Alternatively, if you’re worried of false negatives, one option could be to add a list of KNOWN_AVAILABILITY_STATUSES
, that lists all the status codes that were seen before / are supported. If the script sees a code that it doesn’t know, then it could log it explicitly and maybe allow the list to be configured?
:tada: This issue has been resolved in version 0.16.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Missed this issue and just saw the PR instead before merging. Agreed, it would be nice to know a KNOWN_AVAILABILITY_STATUSES
. CAMPSITE_UNAVAILABLE_STRINGS is early code. I'll take a look at optimizing this soon. Thanks for the contribution in the meantime!
Hi đź‘‹
First of all, thanks for maintaining this project. I just started using it recently and I’m very excited at the idea of potentially finding a campsite!
I just ran into a problem today: I’m getting notified for campsites, but the notification says « Availability status: closed » and on recreation.gov, the campsites show as « unavailable ».
Here’s the command I’m using:
And an example campsite that is being returned: https://www.recreation.gov/camping/campsites/947