Last modified: 2014-09-01 23:22:41 UTC
All bugs related to effects with 127.0.0.1 IP address being used for various automated tasks.
What about ::1? :)
Thanks for filing this. I had a similar thought about creating such a tracking bug as I filed bug 58258. (In reply to comment #1) > What about ::1? :) The bug summary should probably include the word "localhost", no?
Hm.. just a thought... we are just about to remove rc_cur_time from recentchanges (bug 40667).. what about re-using this field for providing timestamp of rc_ip? For delayed jobs we would have an actual change timestamp (rc_timestamp) and "IP address timestamp" (rc_cur_time, maybe renamed)... Similar timestamp would have to be added in other tables like logging or checkuser. Just an idea.
What does the "timestamp of rc_ip" mean? My understanding is nothing should be marked with 127.0.0.1/localhost as the editor (when this happens, it's a bug), regardless of whether it's delayed.
That would be ideal not to have 127.0.0.1. I'd say something like this: IP A.B.C.D issues request on Tue Dec 10 19:23:50 UTC 2013. This request has some delayed/callback/whatever processing that gets executed two minutes later, Tue Dec 10 19:25:50 UTC 2013. This request gets logged with rc_timestamp 201312101925 rc_ip A.B.C.D rc_cur_time 201312101923 - the time when the request from A.B.C.D was taken.
