PolicyEngine / policyengine-api

PolicyEngine's REST API for computing policy impacts.
GNU Affero General Public License v3.0
10 stars 21 forks source link

get_analysis fails to properly fetch existing policies #1510

Closed anth-volk closed 4 months ago

anth-volk commented 4 months ago

At least, that's what appears to be the issue on the front end

anth-volk commented 4 months ago

Update: The issue here is that the Python worker responsible for calculations doesn't have access to the Anthropic environment variable, so any attempt to generate an API output causes the worker to fail. This then raises an error, preventing proper functioning of get_analysis.

MaxGhenis commented 4 months ago

Huh, why does it work intermittently?

anth-volk commented 4 months ago

There is a possibility I’m wrong on the source of the issue. I’ll need to talk with Nikhil to figure it out, since this also wasn’t an issue with our GOT configuration, and I’m starting to wonder if the issue is something different. I should also comb through the GCP API logs to see if I can find the 500s, that might provide some extra insight.

  1. máj. 11. dátummal, 0:34 időpontban Max Ghenis @.***> írta:

 Huh, why does it work intermittently?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.

anth-volk commented 4 months ago

Looking into the Google Cloud console, it actually appears to be driven not by env var issues, but instead by the custom thin ORM built on top of the database. One constant pain point has been argument handling - at times, it's easy to accidentally pass too many or too few arguments to a SQL request, causing a crash, and at other times, it's very easy to incorrectly write syntax that passes arguments as raw arguments, instead of as a tuple. The need to replace the thin ORM with more standard SQLAlchemy handling is open in #1419. This would also solve another pain point, which has been that the current thin ORM only properly handles SQL NONEs and Python None-types in certain settings, while treating Python's None as a string in others.

In this case, it's unclear as of yet what's driving it, so I'll have to do more digging, which is challenging as everything works properly on my system.