codecov-commenter
commented
3 months ago Codecov Report
Attention: Patch coverage is 40.00000% with 12 lines in your changes missing coverage. Please review.
Project coverage is 74.65%. Comparing base (
b769232) to head (93f40fe). Report is 19 commits behind head on main.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| garden_ai/client.py | 9.09% | 10 Missing :warning: |
| garden_ai/backend_client.py | 33.33% | 2 Missing :warning: |
Additional details and impacted files
```diff @@ Coverage Diff @@ ## main #501 +/- ## ========================================== - Coverage 74.81% 74.65% -0.16% ========================================== Files 55 56 +1 Lines 3756 3772 +16 ========================================== + Hits 2810 2816 +6 - Misses 946 956 +10 ```:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
closes #497
Overview
This PR includes logic to toggle the sdk's use of
/garden-search-recordroutes on the backend, similar to the local_data toggle (but was much simpler in practice).Discussion
The dev backend has already deprecated the
/garden-search-recordroutes, which was handy for testing this. When it's time to "flip the switch" on the migration, my plan is for the SDK side to just cut a new release with thelocal_dataandglobus_search._IS_DISABLEDconstants hardcoded toTrue. The subsequent cleanup PR can worry about the unreachable code left over as well as tidying up the schemas we no longer need in a local-data-free world.Testing
Manually, with
garden create;garden publishandgarden delete. Since these were the only operations that touched the search index this was enough to convince me. Because the dev backend already syncs with the dev search index, I was able to see the changes propagate through on the staging frontend despite not calling the/garden-search-recordroutes anywhere.Documentation
n/a
📚 Documentation preview 📚: https://garden-ai--501.org.readthedocs.build/en/501/