Figure out why addresses are getting trimmed

[peppy]

We've had ongoing cases where store addresses are getting trimmed. This happens for some users when they enter a street address or postcode that contains multiple words, where some words are removed completely.

We've added logging to try and track this down, but if anyone has an idea of how this could happen (and can cite in the code where the issue is, or submit a pull request to fix it), that would be pretty cool.

As it has caused a few orders to go missing or returned-to-sender, I'm willing to offer a bounty for a solution to this one.

Note that this does not always happen. It is likely a specific browser or workflow which causes it to trigger.

What needs to be done:

• Figure out why the street / postcode (possibly others) fields in osu_store.addresses occasionally get trimmed.

Bounty offered: 50

[peppy]

Here are some examples of cases where this happened:

street

60 Grafton Lane became 60
hofakkers 41 became 41
Hofgeest 230 became Hofgeest

postcode

V3R 1S9 became V3R

[echojc]

Does your logging in postNewAddress show whether the truncated addresses are being received correctly (and therefore trimmed afterwards) or are being received by the controller with parts already missing?

[peppy]

I haven't checked the logs yet... been waiting for the issue to happen since we added logging to be honest. Should have results from the later this week after we send out the next batch of orders.

[ITzNybble]

My first thought is that of echojc, if this is something that cannot be replicated then it would seem to me that we are losing / truncating the string before being received. I am setting up the environment now.. taking some time but will take a look when its all up and running.

NOTE: I am a C# Developer Mainly but love a challenge, I just found out that I can contribute to osu! so this is great. Cannot wait to help out however I can.

[ITzNybble]

Also If a database is being utilized, I assume it is, The case could be that the truncation is occur within the databse (storing, Retrieving, updating, etc). Just a thought

EDIT: I also want to state that PHP just handles data and that CSS is what handles displaying of the data. It could be due to the CSS not displaying the strings correctly due to an outdated browser (unsupported) I am researching into what is the best practice to prevent something like this.

[peppy]

The issue is definitely not at the database side.

[Nicarim]

@ITzNybble isn't address sent via POST request? If so, it has nothing to do with URL?

[thehowl]

You could also argue this is because the POST request is incomplete. But even the beginning of an address is trimmed, as shown from the hofakkers 41 example.

[Nicarim]

I'd check if it's either javascript part or php part failing with that, and then start working from that (unless it's already known which side fails?)

[ITzNybble]

I guess I am curious now as to when does the trimming happen? after clicking Add new address? or after moving to Paypal? if it is after clicking add new address it is within the POST new address or javascript that handles anything to deal with that. if it is after sending to Paypal then I would need to look else where...

[peppy]

• It's a POST not GET.
• We are using HHVM, not PHP.
• It's nothing to do with the length (you haven't been reading; should be obvious from opening post).

[peppy]

Also why even mention PayPal? have you looked at the code before replying here?

[ITzNybble]

My apologies, I thought I understood the issue I will re-read and try to understand better.

I brought up Paypal because I thought this was the web store for the osu! site and I was browsing that and noticed it sends you to paypal. I suppose I am wrong in that thinking as well. Sorry to waste everyone's time I was just trying to help. :(

[Tewki]

Is it possible to get at least a user agent / browser version of one of the people who it has happened to? Because it's more than likely a client sided problem since there's nothing in your code that would trim it and the addresses doesn't contain multibyte characters.

[PieInOblivion]

I once read that strings not stored in 'EXAMPLE' are sometimes not stored correctly.

[Off-Topic]
Also, wasn't PHP 7 supposed to use almost 5x less memory than HHVM and only the slightest bit slower, close to not even measurable? (Would save on server costs)

[peppy]

No idea what you mean by 'EXAMPLE', but likely not related.

[Off-Topic[
Leave servers to me. This project is portable so it's not a huge issue.

[claudiodekker]

Tried to figure this one out, but I don't see any flawed code.
Perhaps it has something to do with Legacy Browsers?

The only 'weird' thing I came across was this line, although it shouldn't have any effect on actual validation:
'zip' => ['required', 'required'], (postNewAddress() method)

I've personally tested this on the following browsers without issues (Platform: OSX):

• Google Chrome 45.0.2454.93
• Mozilla Firefox (Developer Edition) 42.0a2 (2015-09-19)

That said, for those wanting to troubleshoot this one but cannot access the store bit, you can use the (partial) SQL content dump posted by @peppy on this issue. All you need to do afterwards, is make sure you have at least one country record available in osu.osu_countries.

Example country record:
INSERT INTO osu_countries (acronym, name, rankedscore, playcount, usercount, pp, display, shipping_rate) VALUES ('nl', 'Netherlands', 0, 0, 0, 0, 1, 1);

[peppy]

I think we may have figured this out.

We had a few more cases recently and it would seem that (in the cases which were not user error) the addresses that were showing issues had been entered way back in 2014. This is so far back that it was before we basically rewrote the whole system, and as such there was probably a bug causing issues with saving the addresses.

The reason it was showing in newly placed orders is that people were using addresses that they entered in the system a long time ago (but never used in an order) for new orders. I've addressed this by removing all old addresses which weren't attached to a valid order, so we shouldn't have this occurring again in the future.

Thanks to everyone who looked into this, and sorry I couldn't really give out bounty for the issue.

[peppy]

This is still happening. Had two orders with street name missing (but number present)

production.INFO: {"tag":"NEW_ADDRESS","user_id":12345,"address":{"first_name":"Jared","last_name":"Fiddle","street":"6530","city":"Chanhassen","state":"Minnesota","zip":"55317","country_code":"US","phone":"(952) 123-4567"}}

production.INFO: {"tag":"NEW_ADDRESS","user_id":12345,"address":{"first_name":"Shizl","last_name":"Boxor","street":"14","city":"Hadera","state":"Israel","zip":"12345678","country_code":"IL","phone":"123-4567"}}

😕

[Haxel59]

Why not changing "Street Number..." by "Street","Number","Building... (optional)" ? (It should fix the problem)

[notbakaneko]

Doesn't seem to be happening anymore