Manually parse JSON input

[nlordell]

It looks like the driver is not setting reasonable content-type headers for requests to external solvers. This leads to issues with fastapi which doesn't "parse" (not sure if this is the correct term) the JSON body into the BatchAuctionModel class.

To work around this, manually parse the JSON into a batch auction model.

This PR is currently a draft as I'm exploring other options to make this work.

[bh2smith]

Hey @nlordell - I think this recent PR bumping the version of fastapi may be the cause of issue here:

#7

I wonder if this is a bug on the fastapi side or if we should maybe roll back the package update. I may try and look a little closer at the "breaking changes" (although I wouldn't expect such breakage on a minor version bump).

Actually it looks like they are already at version 0.77.1 (here we use 0.62.2) so it might be worth updating all the way.

[nlordell]

I wouldn't expect such breakage on a minor version bump

Note that in SemVer versioning standard, breaking changes are allowed from 0.x to 0.y (this isn't considered a minor version bump because of the 0. major version):

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[bh2smith]

Whatever you want to call it, it shouldn't have broken this, but it did. Oh wait. You mean anything starting with 0. Can just be broken any time? In that case I should probably have published Dune API with a way lower version number.

[nlordell]

You mean anything starting with 0. Can just be broken any time?

Yes.

[nlordell]

edit: I tried configuring the route parameters so that it accepts bodies without application/json content type, but AFAICT is not possible.

I also found where the issue was introduced:
fastapi/fastapi@fa7e3c9

Note that it has since been fixed here:
fastapi/fastapi@edf6b2d

This means that this PR shouldn't be needed if we upgrade the fastapi version.

Regarding:

I think this recent PR bumping the version of fastapi may be the cause of issue here:

We probably need to setup sufficient CI in order to validate that this continues to work as requirement versions get bumped. Also, have you considered using a different library (Flask comes to mind) that has a slightly more stable API?

[nlordell]

Also created this PR in the services repo which would make this no longer necessary: cowprotocol/services#201