fix: extend from IntEnum in RequestState to fix serialization

[vdusek]

Closes: #551

[janbuchar]

1. let's consider if we want to keep this compatible with crawlee-js, where we store numbers
2. we could just use IntEnum or (str, Enum) - https://docs.pydantic.dev/dev/api/standard_library_types/#enum - I don't want to maintain duplicates of standard library code

[vdusek]

let's consider if we want to keep this compatible with crawlee-js, where we store numbers

I see a slight advantage in serializing it as something more readable, like {"state": "Unprocessed"}, instead of using just numbers, such as {"state": 1}.

we could just use IntEnum or (str, Enum) - https://docs.pydantic.dev/dev/api/standard_library_types/#enum - I don't want to maintain duplicates of standard library code

Oh, that's good, thanks.

[janbuchar]

let's consider if we want to keep this compatible with crawlee-js, where we store numbers

I see a slight advantage in serializing it as something more readable, like {"state": "Unprocessed"}, instead of using just numbers, such as {"state": 1}.

Yeah, I agree with that. I guess it boils down to whether we want the two formats to be compatible. Frankly, I don't see any advantage in that.

[vdusek]

Yeah, I agree with that. I guess it boils down to whether we want the two formats to be compatible. Frankly, I don't see any advantage in that.

Ok, let's use IntEnum then.

[janbuchar]

Yeah, I agree with that. I guess it boils down to whether we want the two formats to be compatible. Frankly, I don't see any advantage in that.

Ok, let's use IntEnum then.

Just so we're clear, we're both OK with string values, but we're keeping the integers for the sake of compatibility, right?

[janbuchar]

Could you also incorporate the test changes from cadlagtrader@02a5c6b?

[vdusek]

Could you also incorporate the test changes from cadlagtrader@02a5c6b?

I already implemented a new test covering this.

[janbuchar]

Could you also incorporate the test changes from cadlagtrader@02a5c6b?

I already implemented a new test covering this.

Yeah, I mean just to make it clear that the reported issue is fixed 😄

[B4nan]

We can change the enum in JS version to store numbers, no problems with that. Generally speaking, numbers will be more performant and less memory sensitive than strings, but we already store a lot of stuff in the request object that I doubt this can be measurable.

[janbuchar]

We can change the enum in JS version to store numbers, no problems with that. Generally speaking, numbers will be more performant and less memory sensitive than strings, but we already store a lot of stuff in the request object that I doubt this can be measurable.

...apparently, that's already the case. The performance impact is most likely non-existent, yes.