It happened to me on FB diplo that I entered three builds for England including an army in Liverpool, and that one did not show up. I am certain I entered the move and updated.
When you have 17 moves to enter you may do mistakes, when you have three ones it's less probable, especially considering that I logged off and on, and the three build moves were still there to be seen.
Another guy told me he had the same exact problem with build liverpool among three english builds, and id like to know whether that happened to any of you?
Ive asked Chris who manages the FB app and im curious to read his answer.

@Dingleberry: PHP actually does have bugs. I remember my friend trying to write a portal in PHP, and having a hell of a time with a login feature not working properly. Finally in frustration he contacted the PHP devs - it was a bug in PHP itself, not his implementation, which was perfectly to spec and should have worked. When the devs of the language say it's supposed to work a certain way and it doesn't, that's a bug. Programmer error would be if he had not implemented properly.

NPRZ you can view the orders you entered as they came into the server prior to processing here: http://phpdiplomacy.net/doc/nprz.txt
(I expect one of either order ID 1879800, 1879801, or 1879802 is the problem order)

Judging from the logs it looks like the order was never placed. The Hold order remains unchanged throughout. Maybe you set it, forgot to update, and moved on to chat or something? Maybe because one hold order was next to 2 others that you had intended it made them easier to miss? Who knows?


> @NPRZ - I'm with ya man. I've been programming longer than
> Kestas has been alive. He may swear it is impossible, but I
> know better. NOTHING is impossible when it comes to software bugs.
Well this is a good opportunity then, and perfect timing. I'm sure you'll be able to draw on some of your experience and give me your thoughts on the critical code section: http://phpdiplomacy.net/doc/phpDoc/__filesource/fsource_Board_Orders_boardordersorderinterface.php.html#a239

To save you time this is the line I'd particularly like your guidance on:
fwrite($orderLog, print_r($_REQUEST['orderForm'], true)."\n\n") or trigger_error("Couldn't write to order log file.");
You mentioned being too busy to analyze systems, which I understand, but other than setting up filehandlers (generally success or failure affairs) there's not much else to order-logging than that.


I'm wondering how that line, the first to read the contents of the order form and the one which writes it to the orderlog text files, could replace a string like ..
" [1879793] => Array
(
[type] => Move
[toTerr] => Paris
)
"
.. with ..
" [1879793] => Array
(
[type] => Hold
)
"
.. over a dozen times in a row on different requests, for that particular order, without it happening like that before or since.

Normally I'd say PHP standard library functions wouldn't have any code capable of repeatedly recognizing and replacing one valid Diplomacy order in print_r array format with another one, but nothing is impossible with software bugs after all.


You must have some applicable past experience to draw on here, I know you wouldn't repeatedly advertise your seniority and hard-won experience if it didn't have an application or relevance to the problem.

Julien, I wish I still had access to the Facebook orderlogs :-( ever since the move to Amazon I've not had access

Do you remember seeing the finalization screen though? We've had the same mysterious bugs over there as here, and they always came out the same way here and there, as always it's hard (especially knowing the way the orders validation code is organized) to think how a problem could manifest itself now while being dormant.

But without the order logs I can't be sure it isn't a bug or check exactly what happened. :-( I'll ask Chris about it when I get a chance, have you had any luck contacting him?

> Folks, I've been writing code for 30 years. I've seen much weirder
> stuff than this. In any case, it's reported if anybody cares, and I'm
> done.
Again I think you're throwing the big numbers out there without understanding the code first.

We've all had those pain in the ass weird problems that make random order corruption seem pretty tame, but the difference is as an ongoing problem there has been time to set the traps and put in asserts and extra code checks.

I make mistakes and order validation could have had some really weird problem, so order logs were added so we could be 100% about what the orders are when they're being entered, but since then they've never shown the orders the user claimed to have entered. Not once. :-S

So this means the orders are getting corrupted in these bizarre and varied ways before any order processing code has touched it.

It is a problem, but it's an order interface problem. Not that there's a bug, but something needs to be done to make sure users have entered the users they intended (without bugging them). Hopefully the SVG map and AJAX orders form will make these problems rarer

> Maybe we should be looking carefully at the hairy javascript that
> handles the menus?
JS doesn't do much here atm, IIRC it only controls the map history controls and the different coloring for orders which have been changed (and that just changes a CSS property on an onChange event, nothing to alter data)

Also I agree with Rait that there are a lot of programmers thinking of possibilities, but really you don't even have to be a programmer to see the signs that this isn't behaving like a bug usually does

Our minds play tricks on us. Sometimes we read thing wrong. We see Belgium but it actually reads Holland. This is especially likely to occur when we a large number of orders to enter have been think about a wide range of options.
When our mind play tricks on us - the trick is pretty convincing. This why people swear they remember events that never happened etc.

Sounds to me someone made anther mistake and is upset about it (enough at least to claim that there was an error in the programming).

Kestas: My knowledge of php is very limited except for the similarities to C/C++, but is it possible that the problem occurs before logging? On the browser or the hosting level, even? Is there any sort of data relating people who complain about this and a certain browser, them having plura enabled/disabled, etc? I realize it's rather unlikely that you'd know, but it's the only thing that makes sense if what you say is true.

It's often surprising how vivid memories can seem but be entirely, and I mean ENTIRELY, fabricated. It's a pretty common phenomenon, that is at least well documented, if not well understood (though I think it is to some extent). I can't find the article I read recently... but it had some striking examples. Eg. A man was convinced and had vivid memories that when he was a child, his nanny had saved him from abductors. Turned out the nanny was lying to curry favour, but he developed a full and vivid memory of the whole ordeal, even though it never happened.

@kestas - I realize you were being somewhat sarcastic, but I am reviewing the code. It's clear that the order received by the code printing the order table out is written to the log file, and an error is thrown if it can't be written, so the info in the text log should, under any circumstances, match the web interface.

The question is where/when is the data written to the database? I can find it, but if you throw me a pointer.

Anyway, there are a number of places in the code where between the writing to the log and printing the table the code could divert - but every one of them would be setting off alarms that shouldn't go unnoticed.

@EJ basically nope. Bugs in non-Dip-order-processing software can't do weird Dip-aware things like sometimes exchange certain valid orders around for specific orders (know better than that, har) and the order log makes sure we know what problems were internal and what weren't

I'm hoping human error is making some sense too? Explaining small random errors in received orders every so often shouldn't take this much effort

@kestas, your code example PROVES my point that their could be a bug. You capture it in the php before calling the SQL, but do you log the SQL calls and results? If the SQL fails, what do you do to log that? I log all transaction from both the program side (in my case .NET) and the SQL side (MS SQL Server 2008). I also log on entry AND exit from both with capture datetime stamps. I have caught more errors as a result of blocking and SQL parallel processing than I can count.

Would you please listen to someone who has been in this business since 1982? Open your mind and consider the possibility that maybe, just maybe, something unexpected is happening?

@jbalcorn: Orders records in the pD_Orders table are created after the last process is done.

userOrder and its child classes are where input validation, database updating, order option generation is done, and where the next order form is generated.

userOrder::html() is where it starts: http://phpdiplomacy.net/doc/phpDoc/__filesource/fsource_Board_Orders_boardordersorder.php.html#a326

userOrderDiplomacy etc generate the actual options for each part of the order (type, toTerr, fromTerr etc), and userOrder uses them to validate input and give a dropdown


That's about it, hope you find something interesting

> You capture it in the php before calling the SQL, but do you log the
> SQL calls and results? If the SQL fails, what do you do to log that?
An error is triggered, stack trace and environment variables (including the SQL) are logged to the errorlog directory (and displayed to screen if you're in dev mode), and any database changes are rolled back. Does the trick for dev/early release, but after a while they pretty much stop.

As an aside do you log every query and result just in case a query fails? Seems a touch excessive, we couldn't do that here even if it was worthwhile.

I'm not really sure what you're getting at though, the code I showed you just saves orders to a text file, the incorrect order has already appeared by the time full SQL logs would give any more information.

Keeping full SQL logs is a weird suggestion for a problem that's not database related. :-|
Logging, in any amount of detail, the path and processing of already invalid data probably won't shed much light on things.


> Would you please listen to someone who has been in this business since
> 1982? Open your mind and consider the possibility that maybe, just maybe,
> something unexpected is happening?
I have this strange mental picture of you doing the Jedi mind-hand-wave as you say this. Does it usually get people with a firm grasp of their platform to accept condescending nonsense and arrogantly presented misunderstandings based on an irrelevant platform?

Everyone makes mistakes (maybe not quite so many or with quite so much arrogance), but for your own sake please drop the age nonsense. It only works when you know what you're talking about. :-/

There is one serious problem with the bug theory:

It requires the logger to be getting it wrong and the database to be getting it wrong in exactly the same way. Surely that means that the only reasonable way it could happen is for the error to exist client side. Basically, you are either claiming that we have found some new way in which php's drop-down lists don't work, which the 20,000,000 other domains that use php don't seem to have, or you are cornered into accepting that its actually your fault, and you misordered.

That sounds logical to me.

As an aside, I've played 74 games here (and over a hundred on a previous ID that has been retired) and have never had a problem. I don't want to be part of the silent majority any longer. A few complaints about a 'bug' shouldn't allow others to think that the vast majority of players have experienced this; they haven't.

In a previous thread on this subject I suggested that the 'bug' had happened to me, thus adding weight to the arguments of NJPW, Draugnar, et al.

Having re-considered, and after following this thread with interest, I'd like to ret-con my earlier comments. I'm sure that in fact, it was almost certainly my mistake, and I have therefore not been affected by any bug.

Armchair psychobabble analysis and arguments about age and comparing project sizes aside (both of which I assure you I would win, lol), and particularly the ones decrying the complexity of having "17 orders" to enter, the fact is I had three moves that mattered, the one that went MIA is the first one I entered, I read and re-read all of them, many, many times, and then it didn't happen.

And I've had previous incidents, one of which specifically defies explanation since I wanted to hold, and the unit did not.

I don't have a mouse, I use a laptop. There is no scroll functionality available (otherwise that would have been my first assumption, too).

As I said, I'm now taking screen shots and time will tell.

> comparing project sizes aside (both of which I assure you I would
> win, lol)
I think this is the first time anyone has brought up project size ;-P

As far as I care you run twitter and Draugnar is the oldest SQL Server developer on earth, as long as you both understand this doesn't have any bearing on your order logs, which are hard to dismiss.

In your case 8-9 updates were made to the order screen, none of which contained Paris. Even if the first one had contained Paris all the following order sets don't.
If your Paris order, which you say was returned back many times, made it through the logs disguised as a Hold order that still doesn't explain why the double-checked Move Paris order then reverted back to the Hold as given repeatedly in the order logs after you were finished checking.

I'm not calling either of you liars of course, but you both have to see that from my point of view the data is conclusive; if the orders changed after you submitted them they changed before being logged, if the returned order form showing the orders as you entered them they must have changed (back) to the original ones after leaving the server.

The data going in and sent out shows everything a-ok, which leaves me pretty helpless. What am I supposed to do?
I think for anyone looking at this data without having experienced submitting the orders themselves there's only one possible explanation

@kestas - I've emailed Chris and he didn't reply. The other players accepted that I pause the game until the matter is investigated, but I don't want to make them wait for too long, so I emailed Chris again. He hasn't gotten back to me yet. If you have any way to contact him it would be very helpful.
If he does not get back to me soon, I'll accept the loss and unpause the game. But I think it's worth investigating cause there may be a bug there. I do remember having seen the finalize screen. As I said I logged off and on and the three orders were still there.

Thanks for your help in any case.

@kestas, I was shooting for a "mine is bigger" joke. :)

I completely understand your position, I've been there many, MANY times in the past 30 years: mystery bugs that make no sense and that I can only doubt based on what I see from the code side... Again, I'm just reporting it for posterity, and now I'm keeping screen shots.

I'm super-picky about this stuff. You'll notice that the "three moves to win" orders included a bunch of unrelated orders. This was specifically because I feared the possibility that the three important ones would fail somehow -- even though the losing player was literally giving me the win by moving out of the way. It was all coordinated and simple, and very closely inspected.

I would offer to poke around in the code myself, but I haven't taken the time to do anything with php other than minor phpBB tweaks, and I'm simply slammed with other work right now.

So the best I can do for the moment is take a bunch of screen shots and perhaps prove (or disprove!) that it happens at all.

I have been taking screen shots since about 10 days ago. Nothing happened so far.

@Draugnar - The point is, the text logs always match what is in the database. He logs received orders to the text file, processes them, then puts them in the database. If we found orders in the text log that weren't in the database, then we would have a problem.

In every case, the orders executed were present in both the text log and database. The orders intended were either not in either place, or were earlier orders that were then overwritten.

how do you take screenshots?

Pressing the print screen button and pasting that in paint?

hooray!