[FX.php List] Weird session variable issue

[Leo R. Lundgren]

19 dec 2013 kl. 19.02 skrev Bob Patin:

>> Why don't you simply take the advice from this thread and actually figure out the problem instead of creating another unwanted workaround for a problem that clearly has a cause? I agree with you completely; You should really not have to change the entire architecture of your application just because of this problem. There's a reason it happens, you just have to find it.
> 
> I agree, but I just can’t find it. I added a 2nd function to write to a test DB after each form (there are essentially 5 stages when data gets pulled in and written); when this problem occurs, *nothing* gets written into the test DB. Here’s my simple process:
> 
> FORM gets submitted (using JQuery) and GET;
> Values are saved into session variables;
> Function is called which writes these session vars to a test DB
> 
> This fails when this error occurs.

Yeah, so one of the things you want to do is simply track the data through this process. We know that in the end the data isn't "there". But at which point does it "disappear"? That's what you want to know.
On the topic of isolating the matter, there are many places to checkpoint the data, but here are a few:

> FORM gets submitted (using JQuery) and GET;
1) Here - What data does the server see/get (and I mean right at the start of the processing of the request)? Does it get what you expect, or does the problem happen this early?
> Values are saved into session variables;
2) Here - Assuming there was actually something to save (depending on #1), was the data really put in the session variables the way you expect? Can you access/dump the session variables and see the data in there, the way you expect it to have been saved in the session variables?
> Function is called which writes these session vars to a test DB
3) Here - At least two things; At the point where you give the data to FX.php, is the data you expect what is really handed over, or has it "disappeared"? Inside FX.php, is it really sending the data that is expected to be sent (short of network traffic checking, this is as close to the PHP -> FM transaction as you can get, AFAIK)?

See what I mean? Just adding that test function you added doesn't answer any of the questions above - all it tells you (when you're not seeing the data in your FM tables) is that "at some point after you pressed the submit button in the browser, and until you checked the FM table, the data was lost". As you read that sentence you'll realize that this did nothing to isolate the matter.

What you need to do is break down the task/process that you have a problem with into smaller pieces, and then inspect and verify state and data in them (starting with one, either one that is suspect or just the middle one to get the most isolation done). Then do that again and again until you know that "OK, before X happens data is fine, and after X data is no longer fine - I wonder why, let's look closer at X" (X being code, a request of some sort, or whatever).

To get answers to the above questions the most straight forward way is to simply dump the appropriate values. E.g. $_GET (if that's what you're using, $_SESSION, etc).
If you can reproduce the problem on demand that's great, but as I understand it you can't. Since the problem happens randomly, when you might not be looking, it's a good idea to log the debugging info you generate into a file or similar (I most often simply use the error log for PHP, e.g. error_log()). Then you can track the entire process from when a user starts the four steps and should be able to find out where it happens.

I hope that makes sense. I'm trying to convey understanding of how to approach problems like this systematically (although what I wrote doesn't cover all of the things that one should consider/check/do).

> I’ve tested on my Mac dozens of times, with various browsers; I’ve tested on Windows 7, I’ve had a consultant test on XP, I’ve had the client test on her machine using Windows 8. In *all* of our tests, it works perfectly.
>> 
>> It seems to me that you're not doing the debugging that is needed. For example, to verify whether the URL length issue is a problem, you'd simply log the data that comes into the application and investigate if it's cut off at that point already, in the case when data isn't saved the way you expect. This is on the same topic that I mentioned initially; Track the data and flow of things through the request cycle, in order to find the place where things go wrong.
> 
> But the length of the URL is nowhere near 2000 characters; if I had to guess, I’d say it’s 200-300 characters.
>> 
>> Again, it's all about isolating the matter to a smaller part of your application, verifying that the what you think is in front of you is really the case (e.g. variables of any kind having the data you think, business logic taking the path you think, etc), and then you should be able to find that the problem happens in one and the same place, and then you're very much closer to an actual solution instead of a workaround. It's just code. Short of memory corruption and other "off" things, which would probably cause other types of symptoms, it's just code that does what you tell it to.
>> 
>> Just saying. I mean, your problem is that data is "disappearing". It doesn't just magically do that at random places in your code. One of the first things you want to know when having a problem like this is at what point data isn't what you expect it to be. One of the last things you'd want to do is changing the architecture without even knowing why.
> 
> I agree with all that, but if I can’t duplicate it, I can’t spot it; I can’t even get back anything amiss when I test, so that’s why I’m totally stumped.

Generating debug data and logging it so that you can go back and see the debug data once you know the problem has occurred, is what you need to do if you can't summon the problem at will.

Ask yourself questions like "At point X in the application, does $foo contain what I expect it to contain?". If you cannot answer that question with 100% certainty (yes/no), then ask yourself "How can I investigate it?" and then you'll find yourself generating debug data.

> If I could duplicate it I could find and fix it; without its occurring on my machines, I don’t know where to turn next. I went through the whole site to make sure that I didn’t have a session_destroy() command somewhere that it didn’t need to be, and confirmed that I’m not destroying the session anywhere but at the end of the process.
> 
> The other thing that I know is that FileMaker isn’t failing to create a record; I have error code in there that would email me if that were to happen, but it does write a record—it just doesn’t have anything in it.

Even if FM isn't failing creating a record, we don't know if it's actually getting any data from the PHP side. I would start on the PHP side though, verifying that the data survives until it is to be fired off to the database.

> I agree that it would be better to figure out the issue, but when 90% of the registrations succeed, and when I can’t duplicate the issue (nor can other testers), I don’t know what else to do…
> 
> Frustrating…
> 
> Bob Patin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20131219/55d786e7/attachment.html