This repository has been archived by the owner on Jul 9, 2022. It is now read-only.
sendMessage with attachment will send unordered __req
#52
Labels
Comments
|
In this particular instance, can't it be fixed by uploading the attachment before we create the sendMessage form? We could change our convention to only mergeWithDefault immediately before sending off a form. Could we maybe even integrate it into the post? Just spitballing. |
|
We can't integrate into the post without being sure that it won't break certain post request that don't have all those fields. We don't know what FB's doing with our requests. I think the only way would be to be very consistent, or have two different functions |
|
I wouldn't be against a |
bsansouci
added a commit
that referenced
this issue
Jul 31, 2015
Read #52 for more details, but we're changing the API of each function inside `src/` to receive `defaultFuncs` instead of `mergeWithDefaults`. The former's an object that contains three functions: - get - post - postFormData They are equivalent to the ones in `utils` except they'll merge the given form with extra attributes. Internally they call `mergeWithDefaults`. We removed the ability to call the latter directly because it's a statefull function, and can result in bugs later on (see #52).
how2945ard
pushed a commit
to how2945ard/facebook-chat-api
that referenced
this issue
May 30, 2017
Read Schmavery#52 for more details, but we're changing the API of each function inside `src/` to receive `defaultFuncs` instead of `mergeWithDefaults`. The former's an object that contains three functions: - get - post - postFormData They are equivalent to the ones in `utils` except they'll merge the given form with extra attributes. Internally they call `mergeWithDefaults`. We removed the ability to call the latter directly because it's a statefull function, and can result in bugs later on (see Schmavery#52).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If you look here you'll see that we call
mergeWithDefaults(say__reqis"a") and then callapi.uploadAttachment. The latter will also callmergeWithDefaultshere (say__reqis"b"now) and will send first, after which"a"is sent, out of order.This is a little annoying because it could be caused anywhere due to the nature of how we "cache" the form first, and then send the request (in two steps). I'd love to fix this everywhere, but I'm not too sure how.
Thanks to @JLarky for finding this.
The text was updated successfully, but these errors were encountered: