postgres errors during cronjob about suspicious_login HOT 15 CLOSED

Hi guys, don't want to be annoying, but any progress on this, there were few version upgrades but I still have this error on my home server. Cheers.

from suspicious_login.

Apparently the wrong error is thrown on Postgres. This DB exception is actually expected and handled:

from suspicious_login.

Could it be that the issue is more with the transaction being rolled back than with unique key violation?

from suspicious_login.

I took a bit of a closer look and what I was referring to is indeed incorrect. The stack trace points to

Could it be that the issue is more with the transaction being rolled back than with unique key violation?

You are right in that the code is run in an transaction. The unhandled exception causes a rollback. However, I do not think this is the root of the problem here.

from suspicious_login.

Could it be that the issue is more with the transaction being rolled back than with unique key violation?

You are right in that the code is run in an transaction. The unhandled exception causes a rollback. However, I do not think this is the root of the problem here.

I was thinking that perhaps the exception to be handled at the php level may be an aborted transaction rather than a unique key violation.

from suspicious_login.

You're right. The problem is that postgres does not allow us to continue the transaction after the error. I have to to restructure the code for this.

from suspicious_login.

Hi, no, not really. But if you're interested in doing a little coding and refactoring exercise please let me know ✌️

from suspicious_login.

I haven't analysed the code yet, if you could save me some time and point in the right direction, I can have a try as I do, in 15% of my work, PHP and PGSQL 😄 I'll more than happy to help

from suspicious_login.

What we do (in pseudo code)

try {
    insert()
} catch (…) {
    select()
    if (nothing found) {
        // ignore
    }
    update()
}

What we should do

select()
if (nothing found) {
    insert()
} else {
    update()
}

from suspicious_login.

Hi there, same setup – same error here. I'd be glad if it could be solved 👍

from suspicious_login.

Hi there, same setup – same error here. I'd be glad if it could be solved +1

Just add your 👍 to the original report. Then we know more people are affected. But please don't do these comments. Thanks ✌️

from suspicious_login.

@ChristophWurst I have modified the script locally for testing. So far there are no entries in oc_login_address, oc_login_address_aggregated, oc_suspicious_login nor oc_suspicious_login_model, if these are the tables I'm looking for. Can I trigger ETLService manually, is it php -f occ suspiciouslogin:etl?

from suspicious_login.

There is pull request #166 It cleared the errors in the log, but still doesn't create any entries in login_address_aggregated table.

from suspicious_login.

@ChristophWurst please ignore my last pull request as I found it didn't populate login_address_aggregated with any data. For some reason fetch() didn't return any data but is_null($existing) was always false. This time using fetchAll() and sizeof($existing) == 0 to detect if the record is in the table. So far it works fine and I have some data populating in the table. New pull request is #168 please review and try.

from suspicious_login.

Hi there, same setup – same error here. I'd be glad if it could be solved +1

Just add your to the original report. Then we know more people are affected. But please don't do these comments. Thanks

Allright, didn't know that was the policy here.

from suspicious_login.