Skip to content
This repository has been archived by the owner on Jul 13, 2023. It is now read-only.

Make message dict a defaultdict #350

Closed
bbangert opened this issue Feb 18, 2016 · 0 comments
Closed

Make message dict a defaultdict #350

bbangert opened this issue Feb 18, 2016 · 0 comments
Assignees

Comments

@bbangert
Copy link
Member

Rather than adding a Message object as the month switches over, it should be a default-dict so that if there's greater clock skew in production, it won't matter.

The only twisted looping task to be to update the current_month var.

@bbangert bbangert added the ready label Feb 18, 2016
@bbangert bbangert added this to the PUSHSVC-0: quality milestone Feb 18, 2016
@bbangert bbangert changed the title Make message dict a defaultdict Make settings message dict a defaultdict Feb 18, 2016
@bbangert bbangert changed the title Make settings message dict a defaultdict Make message dict a defaultdict Feb 18, 2016
@bbangert bbangert added ready and removed ready labels Feb 18, 2016
@bbangert bbangert added in progress and removed ready labels Mar 5, 2016
jrconlin added a commit that referenced this issue Mar 7, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 7, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 15, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 15, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 15, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 15, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 17, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 17, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 17, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 21, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350

Conflicts:
	autopush/tests/test_integration.py
jrconlin added a commit that referenced this issue Mar 21, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 21, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 21, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 21, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 23, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
jrconlin added a commit that referenced this issue Mar 23, 2016
A user that tries to connect from a period longer than we currently
allow for could cause a "KeyError" on the server. Instead, we should
require that the user use a new UAID, which shoud cause the client to
re-register older connections.

Closes #350
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants