search

alist / domoapis

0 stars 0 forks source link

sometimes supporters get stuck on specific /advice/:adviceID1, even if url /:adviceID2 !! #3

Closed alist closed 10 years ago

alist commented 10 years ago

loading a page like http://localhost:3000/mit/advice/529bd703c4752a0000000009, The logged-in supporter's browser client is seemingly passed the correct adviceRequestId at from controller/organization.js:170. (Low confidence->) Though the window.advicerequestId shows the expected (in-url) id, the inspector shows the client makes a request to the server with an inaccurate adviceRequestId, returning data for a specific and consistent other adviceRequest.

Once this behavior is seen once for a particular run of the app, this is the only behavior a user's session encounters. Data is only correct when the "stuck" advice request is loaded at /advice/:stuckAdviceRequestID

Affected: Time-wise- Unclear whether for particular users, or for all users at once. User-base-wise- unclear whether my account "atlex2@gmail.com" under /mit has characteristics that especially make it express this symptom

Workaround: Restarting the app fixes..

Reproducibility: Not known. It just "seems to happen" every once in a while. Not uncommon.

Thoughts: Perhaps it's an auth issue, as user sessions are not persisted between app restarts. Not sure what this means for the likelihood of this being either a client or a server issue.

*from controller/organization.js:130*
We force org-supporters to view advice a supporter in orgID: 520aa16e4b2fbb237d000027
*from controller/organization.js:151*
advicerequestId in 52a676503968b4040000000c
got to orguser select
5250b77da40cef040000000b //userId
520aa16e4b2fbb237d000027 //orgId
5250b77ea40cef040000000c //orgUserId
exiting orguser select
advicerequestId out 52a676503968b4040000000c

lines #s from https://github.com/alist/domoapis/tree/375a8a4d642e421fad932a22ebf68e38bceaf60e

alist commented 10 years ago

More details confirm the low confidence section above!

When in this state, I go to http://localhost:3000/mit/advice/52b378cda9e320040000000c & it displays data for 52b37e84a9e320040000000e

In fact, I go into my js console on the client end and

Furthermore, http://localhost:3000/mit/adviceRequest/52b378cda9e320040000000c does indeed return the appropriate data for this state

Thus it appears that either: 1) the browser is caching the JS file with the updated advicerequestId OR 2) the jade file is not writting the proper advicerequestID

In fact, I look at the bottom of the html in the giveadvicedetail page and see:

<script>
      advicerequestId="52b37e84a9e320040000000e";
      successLabelText="Thank you for supporting!!"
</script>

AHA- I think. It's the template. But I'm not so quick to blame jade or our server. I look at the status code for a completely bogus url, http://localhost:3000/mit/advice/garbageid and see: Status Code:200 OK. Furthermore, refreshing yields 304 Not Modified. Deleting cookies doesn't solve problem.

shirish87 commented 10 years ago

Steps to reproduce:

Result: Previous advice request

Solution: I'll fix it if you promise not to rant about JavaScipt :D

alist commented 10 years ago

JS! -- We should've been using coffeescript! :D

Shirish you crazy guy! Please explain what's been going on here, I don't see what's happening with the scopage! :-) :-)

Is advicerequestId set once and made a static var for the entire advicerequest.js file? I.e., if I were to make another new advice for a different ARId, would the "Stuck" AR change?

harishnk commented 10 years ago

Whoa...yes. Using var will create a variable respecting scope. Doing a direct assignment (omitting a var) will cause the creation of a property which will assign itself to a same-name variable if there is a var declaration up above in the chain, else the system creates a property with global scope.

Coffeescript assumes that a similar declaration is a variable. To create properties, u have to do a window.property which prevents one from accidently creating properties. IMHO a small advantage :P

Harish Kamath hnk.im | me@hnk.im

On Sat, Dec 21, 2013 at 9:46 AM, Alexander List notifications@github.comwrote:

JS! -- We should've been using coffeescript! :D

Shirish you crazy guy! Please explain what's been going on here, I don't see what's happening with the scopage!

Is advicerequestId set once and made a static var for the entire advicerequest.js file? I.e., if I were to make another new advice for a different ARId, would the "Stuck" AR change?

— Reply to this email directly or view it on GitHubhttps://github.com/alist/domoapis/issues/3#issuecomment-31068107 .

shirish87 commented 10 years ago

@harishnk Although the fix works, there's some strange behaviour here. Will update later.