node independent filter middleware #732

dylanjw · 2018-04-01T16:03:51Z

What was wrong?

See #551 (tldr; node filters suck)

How was it fixed?

Added a middleware that stores a "filtering generator" keyed by filter id. Calls to getFilterChanges will retrieve the stored generator and retrieve logs via eth_getLogs.

Features implemented:

Limit the eth_getLogs request size by set number of blocks.
Works with dynamic block ranges
- toBlock = 'latest'
- ~~toBlock = 'pending' (need to test)~~
eth_newFilter
eth_getFilterChanges
eth_getFilterLogs
block filters
~~[ ] pending transaction filters~~

TODO:

Clean up tests: split tests up; unittests to tests/core/middleware, functional/integration to tests/core/filtering
Write more tests. In particular:
- Check for missing or overlapping blocks in the results. (assumptions were made)

Cute Animal Picture

pipermerriam · 2018-04-02T14:57:25Z

web3/middleware/filter.py

+def unload_latest_blocks(web3, fromBlock, toBlock):
+    _fromBlock = fromBlock
+
+    current_block = int(web3.eth.blockNumber)


Is something returning a non-integer for this?

No. I misread an error and added this and didnt remember to take them out.

pipermerriam · 2018-04-02T14:59:39Z

web3/middleware/filter.py

+            return _start, _end
+
+
+def unload_latest_blocks(web3, fromBlock, toBlock):


It's not clear to me what this function is used for (still ingesting the PR). Maybe add a docstring to explain the intent?

I'll add a docstring. I was having trouble naming this function.

It returns block ranges starting from fromBlock to the latest mined block, until reaching toBlock. e.g.:

>>> blocks_to_filter = unload_latest_blocks(w3, 0, 50) >>> next(blocks_to_filter) # latest block number = 11 (0, 11) >>> next(blocks_to_filter) # latest block number = 45 (12, 45) >>> next(blocks_to_filter) # latest block number = 50 (46, 50)

get_block_ranges

get_latest_block_ranges

iter_block_rangest

iter_latest_block_ranges

Don't particularly love any of those. The iter_ prefixed ones seems a bit more descriptive/semantically correct.

pipermerriam · 2018-04-02T15:00:50Z

web3/middleware/filter.py

+        # no new blocks
+        if current_block < _fromBlock:
+            yield (None, None)
+        # reach stop_block after being passed by current_block


There is no stop_block in the context here. Is this comment outdated?

pipermerriam · 2018-04-02T15:01:28Z

web3/middleware/filter.py

+            return _start, _end
+
+
+def unload_latest_blocks(web3, fromBlock, toBlock):


We've maintained using fromBlock instead of from_block in most public APIs, but for internal APIs I'd prefer we stick with from_block style casing.

pipermerriam · 2018-04-02T15:02:57Z

web3/middleware/filter.py

+        address=None,
+        topics=None,):
+
+    if not fromBlock or fromBlock == 'latest':


not fromBlock will result in fromBlock == 0 not iterating from the genesis block as expected, but rather just starting at the current block which looks like a bug.

pipermerriam · 2018-04-02T15:03:40Z

web3/middleware/filter.py

+        _fromBlock = fromBlock
+
+    if _fromBlock > int(web3.eth.blockNumber):
+        raise ValueError("fromBlock ({0}) has not yet been mined".format(fromBlock))


I'm not sure this needs to be an error case. Why should we forbid someone setting up a filter in advance? If you want to punt on implementation can you just change this to a NotImplementedError and change the error messaging to indicate that this just hasn't been implemented yet.

I can implement future block ranges.

pipermerriam · 2018-04-02T15:05:21Z

web3/middleware/filter.py

+    filter_id_counter = map(to_hex, itertools.count())
+
+    def middleware(method, params):
+        if method in (


It'd be good to both use a set in places where you are only doing membership checking and to elevate this to a module level constant so we don't have to allocate it every time the filter is called.

pipermerriam · 2018-04-02T15:07:28Z

web3/middleware/filter.py

+
+            filters[filter_id] = _filter
+            return {'result': filter_id}
+        elif method == 'eth_getFilterChanges' or method == 'eth_getFilterLogs':


It looks like eth_getFilterLogs is supposed to have it's own separate implementation? (based on your PR checklist and the differences in their respective functionality)

dylanjw · 2018-04-03T14:31:16Z

Im starting to suspect that a pending transaction filter is not possible. Some of the reasons:

I think it would involve polling the transaction pool, but that carries the risk of missing transactions.
Infura does not yet have any tx pool apis.
API is node dependent (not an impossible problem).

Maybe we could add a recipe to the docs for an alternate way from node filters to get information on pending transactions, in lieu of having the filtering middleware handle it.

pipermerriam · 2018-04-03T15:50:29Z

@dylanjw re pending transactions.

This middleware doesn't need to be functional for anything but log filtering so feel free to drop block and pending transaction filters from scope.
Pending transaction filters provide no guarantees that you'll see all of them anyways, a node can only provide info on pending transactions they know about and there will be plenty that they never learn about prior to being mined.
since there's no guarantees around what pending transactions will be visible to the node and thus exposed in filters, I think it's ok for us to do the following.

A middleware specific to the transaction pool APIs which will only work if they are available (and fails hard if the endpoints are not available).
A middleware that only monitors for eth_sendTransaction and eth_sendRawTransaction and only returns transaction hashes that traverse those APIS

I still think I'd recommend separating this functionality from this PR and doing it as an independent PR to try and limit the scope of this feature.

carver · 2018-04-03T20:50:38Z

If you rebase this on master, some of these errors will be fixed, because master is upgraded to eth-tester devnum 22 @dylanjw

dylanjw · 2018-04-05T00:49:25Z

@pipermerriam I implemented the block filter in the PR because it was easy to do; most of the work is done with the iter_latest_block_ranges(). Is it ok to leave it here?

pipermerriam

My comments thus far.

pipermerriam · 2018-04-05T15:32:01Z

tests/core/middleware/test_filter_middleware.py

+        with pytest.raises(expected):
+            w3.manager.request_blocking(method, args)
+    else:
+        assert w3.manager.request_blocking(method, args) == expected


Is there a reason you are reaching down into the w3.manager instead of using w3.eth.getFilterchanges, w3.eth.getFilterlogs, ...?

pipermerriam · 2018-04-05T15:33:09Z

tests/core/middleware/test_filter_middleware.py

+    ('eth_newFilter', [{}], '0x1'),
+    ('eth_newPendingBlockFilter', [{}], NotImplementedError),
+    ('eth_newBlockFilter', [{}], '0x2'),
+    ('eth_getFilterChanges', ['0x0'], []),


It looks like this entry is requesting the filter which is setup here: https://github.com/ethereum/web3.py/pull/732/files#diff-ddc63b66c3f0acb70cca05f91281a51dR56

Assuming I'm reading that correct, it seems bad that this test is tightly coupled with state which was setup in that fixture, as well as that the test itself is stateful at the module level, which allows for state to leak across test runs. I think it'd be better if this could be refactored to:

not have shared state across test runs

setup the necessary state within this test.

pipermerriam · 2018-04-05T15:37:26Z

web3/middleware/filter.py

+        yield web3.eth.getBlock(block_number).hash
+
+
+def filter_middleware(make_request, web3):


Naming nitpick:

log_filter_middleware (my preference)

event_filter_middleware

local_filter_middleware

Just the term filter_ doesn't quite seem specific enough.

pipermerriam · 2018-04-05T15:39:25Z

web3/middleware/filter.py

+            "Incompatible start and stop arguments.",
+            "Start must be less than or equal to stop.")
+
+    def range_counter(start, stop, step):


I don't understand why there is an outer and inner function call here?

The wrapper is so the exception is raised when the generator is created. e.g.

without the wrapper:

>>> s = segment_count(5, 0) >>> next(s) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "web3/middleware/filter.py", line 45, in segment_count "Start must be less than or equal to stop.") TypeError: ('Incompatible start and stop arguments.', 'Start must be less than or equal to stop.') >>>

With the wrapper:

>>> s = segment_count(5, 0) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "web3/middleware/filter.py", line 45, in segment_count "Start must be less than or equal to stop.") TypeError: ('Incompatible start and stop arguments.', 'Start must be less than or equal to stop.') >>>

Interesting, I wasn't aware that generators were lazy in that way. Neat and also kind of awkward. This deserves a comment imho as it's not clear just by reading the code.

pipermerriam · 2018-04-05T15:45:29Z

web3/middleware/filter.py

+)
+
+
+def range_counter(start, stop=None, step=5):


I think that this whole function can be made significantly simpler using cytoolz.sliding_window

def range_counter(start, stop=None, step=5): if stop == None: base_iter = itertools.count(start, step) else: # todo: if `stop` won't be included in the `range` output, do something # like `cytoolz.concatv(range(start, stop, step), [stop]) to add `stop` to # the list of values that will be generated. base_iter = range(start, stop, step) for left, right in sliding_window(2, base_iter): yield left, right

Haven't tested this code but I think it at least does close to what you are trying to do here with less mental overhead.

Looks like you can accomplish the generator with validation on creation with the following pattern.

def my_gen(): if thing: raise Exception return (v for v in things)

This is assuming that you can fit what you need within a comprehension and still maintain readability.

pipermerriam · 2018-04-05T15:47:10Z

web3/middleware/filter.py

+    """
+    # Return full range if all blocks exist
+    if to_block is not None and to_block <= web3.eth.blockNumber:
+        return from_block, to_block


I don't think this does what you want.

In [14]: def f(v): ...: if v: ...: return 1, 2 ...: yield 3, 4 ...: yield 5, 6 ...: In [15]: tuple(f(True)) Out[15]: () In [16]: tuple(f(False)) Out[16]: ((3, 4), (5, 6))

I think this needs to be a yield statement followed by a blank return statement if you want to generate the single value and then terminate.

pipermerriam · 2018-04-05T15:55:56Z

web3/middleware/filter.py

+            else:
+                yield from_block, current_block
+
+            yield from get_block_range(current_block + 1, to_block)


this pattern isn't going to work as it'll hit the recursion depth limit quite quickly since every step of the iteration requires a new stack frame. This needs to be refactored such that it isn't recursive.

pipermerriam · 2018-04-05T15:56:20Z

web3/middleware/filter.py

+    def range_counter(start, stop, step):
+        def iter_ranges(start, step):
+            yield start, start + step - 1
+            yield from iter_ranges(start + step, step)


Same issue here. This solution is recursive and will easily hit the recursion limit. Needs to be refactored to something non-recursive.

pipermerriam

missing a test for calling web3.eth.getFilterChanges with an unknown filter_id.
would be nice to actually test that the filters work as expected. We could potentially fuzz test this against an eth-tester backed filter via two separate web3 instances (one eth-tester and one middleware backed) to verify that they return the correct log entries.

pipermerriam · 2018-04-10T17:22:57Z

web3/middleware/filter.py

+    def finite(start, stop, step):
+        #  If the initial range is less than the step
+        #  just return (start, stop)
+        if stop < step:


Should this be if start + step >= stop?

pipermerriam · 2018-04-10T17:24:05Z

web3/middleware/filter.py

+        if stop < step:
+            yield (start, stop)
+            return
+        for i in zip(


naming nitpick

for segment in zip(...): ...

pipermerriam · 2018-04-10T17:24:50Z

web3/middleware/filter.py

+                yield (stop - remainder, stop)
+
+    def infinite(start, step):
+        for i in zip(


same naming nitpick s/i/segment

pipermerriam · 2018-04-10T17:25:19Z

web3/middleware/filter.py

+            if remainder:
+                yield (stop - remainder, stop)
+
+    def infinite(start, step):


This could be elevated to a module level function.

pipermerriam · 2018-04-10T17:25:37Z

web3/middleware/filter.py

+    >>> next(segment_counter) #  Remainder is also returned
+    (9, 10)
+    """
+    def finite(start, stop, step):


This could be elevated to a module level function.

pipermerriam · 2018-04-10T17:40:36Z

web3/middleware/filter.py

+@to_list
+def block_hashes_in_range(web3, block_range):
+    for block_number in range(block_range[0], block_range[1] + 1):
+        yield web3.eth.getBlock(block_number).hash


I think that web3.eth.getBlock returns None if block_number is greater than the current HEAD block number, which means this will raise an AttributeError if that case is met.

That is true, I'll handle that case.

pipermerriam · 2018-04-10T17:42:48Z

web3/middleware/filter.py

+            if method == 'eth_newFilter':
+                _filter = RequestLogs(web3, **apply_key_map(FILTER_PARAMS_KEY_MAP, params[0]))
+
+            if method == 'eth_newBlockFilter':


s/if/elif and probably good to add an else that raises NotImplimented.

pipermerriam · 2018-04-10T17:43:32Z

tests/core/middleware/test_filter_middleware.py

+        ))
+
+
+@pytest.fixture(scope='function')


Not highly opposed to this but "function" is the default scope for pytest.fixture

pipermerriam · 2018-04-10T17:45:58Z

tests/core/middleware/test_filter_middleware.py

+    iter_block_number.send(1)
+
+    with pytest.raises(NotImplementedError):
+        w3.eth.filter('pending')


Maybe move this to it's own test?

pipermerriam · 2018-04-10T17:47:08Z

tests/core/middleware/test_filter_middleware.py

+
+def test_local_filter_middleware(w3, iter_block_number):
+    block_filter = w3.eth.filter('latest')
+    assert block_filter.filter_id == '0x0'


Maybe instead of asserting the exact id since this is somewhat testing the implementation, we could have a test that spams a number of different filter creations and asserts that the set of filter_id values that are returned are all strings and are unique.

dylanjw · 2018-04-17T00:34:58Z

We could potentially fuzz test this against an eth-tester backed filter via two separate web3 instances (one eth-tester and one middleware backed) to verify that they return the correct log entries.

@pipermerriam I added a parametrized web3 fixture to tests/core/filtering/conftest.py that runs all the normal filtering tests against the middleware filter and the node filter. Is that what you mean? Or do you want tests with automated inputs? Im not too experienced with fuzz testing.

pipermerriam · 2018-04-17T16:59:09Z

I added a parametrized web3 fixture to tests/core/filtering/conftest.py

Looking at the tests that live under tests/core/filtering I'm not sure we're testing the things I'd like to test. The tests in there look to be more smoke tests that things that really provide coverage for the filter APIs.

Ideally, I think we need a test or set of tests that cover the following.

Filtering across a range of ~20 or more blocks to see that it handles stepping across larger block ranges appropriately.
Variants that are open ended on the toBlock side to see that it correctly handles new block mining.

dylanjw · 2018-05-16T23:21:40Z

I am including tests for the issues mentioned in #836, as well as longer and open ended block ranges.

dylanjw · 2018-09-21T01:27:26Z

Check for missing or overlapping blocks in the results. (assumptions were made)

Im getting a heisenbug, where in some cases all tests pass, and in others there are missing log results. Im guessing this could be due to skipping blocks in the ranged block getLogs calls.

dylanjw · 2018-09-23T22:15:38Z

I added a test that emits an event to 100 blocks in a row, and show that the a "local" filter finds every one. Doesnt add up with my theory that there are breaks in the eth_getLogs block ranges.

dylanjw · 2018-09-24T00:02:38Z

Not ready to merge. Test results are still flaky.

dylanjw · 2018-09-24T23:03:01Z

Function scoped pytest fixtures are not respected by Hypothesis, so the failures have to do with logs in the overlapping blocks between runs, where the chain state is not reset. Im surprised this hasnt been a bigger issue with flaky tests.

carver · 2018-09-25T18:44:42Z

Wow, I can confirm that only hypothesis fails here, reusing integer 2:

import pytest
import itertools

from hypothesis import given, strategies as st

counter = itertools.count()
hypothesis_already_seen = set()
parametrized_already_seen = set()


@pytest.fixture
def next_int():
    return next(counter)


@pytest.mark.parametrize('ignored_text', ('', 'a'))
def test_parametrize_and_fixtures(next_int, ignored_text):
    assert next_int not in parametrized_already_seen
    parametrized_already_seen.add(next_int)


@given(st.text())
def test_hypothesis_and_fixtures(next_int, ignored_text):
    assert next_int not in hypothesis_already_seen
    hypothesis_already_seen.add(next_int)

I would consider this a hypothesis bug. Do you want to open it? If not, I'm happy to.

carver · 2018-09-25T18:46:45Z

Nevermind, it's already there, and old... 😢 HypothesisWorks/hypothesis#377

carver · 2018-09-25T18:49:13Z

There is a workaround, so at least you can check locally if the scoping issue is the only problem you're seeing: https://github.com/untitaker/pytest-subtesthack/

dylanjw · 2018-09-25T19:46:15Z

I have gotten around the issue by taking a snapshot and restoring at the beginning of the test function. The issue with hypothesis actually uncovered a bug, where the local filters were picking up events from the last block of the previous hypothesis run.

Also added snapshot/revert to deal with hypothesis issue

dylanjw · 2018-09-26T16:11:06Z

Im not getting flaky test runs anymore. @carver @pipermerriam Ready for final review.

pipermerriam · 2018-09-26T17:10:36Z

@carver assigned to you, since this was a concept I came up with I think it's valuable for you to do primary review (cause bias...), I can do another pass when you are done if you think it will help.

carver

Just a few things, but then it looks good to go!

carver · 2018-09-26T16:42:33Z

web3/middleware/filter.py

-            range(start, stop - step, step),
-            range(start + step, stop, step)):
+            range(start, stop - step + 1, step),
+            range(start + step, stop + 1, step)):
        yield segment
    else:


This doesn't need to be in an else clause right? Seems like it should always run.

Its a for/else loop, so it runs at the end of the for loop. It would work the same to remove the else clause, but probably safer to keep it in case anything is added to this method.

for/else is typically reserved for loops that have a break somewhere in them, in order to only run the else in whatever case the break does not get triggered (or inversely, having the ability to break, thus skipping the else code.

carver · 2018-09-26T17:23:44Z

tests/core/middleware/test_filter_middleware.py

+        with pytest.raises(expected):
+            block_ranges(start, stop)
+    else:
+        for actual, expected in zip(block_ranges(start, stop), expected):


This will cause problems if block_ranges returns a different number of pairs than expected. zip() will stop short, and could give a green test on a broken implementation.

One option is:

missing_flag = object() comparing_pairs = itertools.zip_longest(block_ranges(start, stop), expected, fillvalue=missing_flag) for actual, expected in comparing_pairs: assert actual == expected

Alternatively, you could capture them into a tuple first and check their length.

pre-check on length gives an early exit and is probably preferrable to complicating the comparison loop with an abnormal exit condition which is that implicitely, nothing will evaluate equal to missing_flag.

carver · 2018-09-26T17:35:34Z

tests/core/middleware/test_filter_middleware.py

+            actual_tuple = next(latest_block_ranges)
+        except StopIteration as e:
+            if e.value:
+                actual_tuple = e.value


iter_latest_block_ranges doesn't seem to ever return anything. What is the goal here? Since StopIteration only seems to be raised in an error case, maybe it shouldn't be caught at all.

I have some bad naming here. iter_block_number is a fixture that allows me to set what web3.eth.blockNumber returns. iter_latest_block_ranges is what is being tested, and sets up a generator latest_block_ranges that has its output assigned on line 115 and checked on line 120. The StopIteration catch is leftover from an older version of iter_latest_block_ranges when I was incorrectly returning the final value, instead of yield. I will take that out.

carver · 2018-09-26T18:12:06Z

web3/middleware/filter.py

+    return (
+        (from_block, to_block - 1)
+        for from_block, to_block
+        in segment_count(start_block, last_block + 1, step)


The default value last_block could be None which blows up here.

Looking at the invocation, it looks like it's always defined, and never None. So maybe just drop the None default value in the signature, and you can drop the last_block is not None check above.

I took out the None handling from this function and segment_count

carver · 2018-09-26T18:17:23Z

web3/middleware/filter.py

+        elif self._to_block == 'latest':
+            to_block = self.w3.eth.blockNumber
+
+        else:


nit I'm not generally a fan of this gap before the else or elif statement. Up to you, though.

carver · 2018-09-26T18:30:50Z

web3/middleware/filter.py

+                    self.to_block,
+                    self.address,
+                    self.topics,
+                    max_blocks=50)))


Probably belongs in a constant with the one from line 235 also.

dylanjw force-pushed the filtering-middleware branch from 4599ba4 to 191584a Compare April 1, 2018 18:14

dylanjw changed the title ~~Add new filter middleware prototype~~ node independent filter middleware Apr 1, 2018

pipermerriam reviewed Apr 2, 2018

View reviewed changes

dylanjw force-pushed the filtering-middleware branch 3 times, most recently from 5cf5c8c to cafbbe9 Compare April 3, 2018 03:37

dylanjw force-pushed the filtering-middleware branch from cafbbe9 to b7cf985 Compare April 4, 2018 20:57

pipermerriam reviewed Apr 5, 2018

View reviewed changes

dylanjw force-pushed the filtering-middleware branch from f40114b to cc14385 Compare April 10, 2018 17:16

pipermerriam reviewed Apr 10, 2018

View reviewed changes

dylanjw force-pushed the filtering-middleware branch 2 times, most recently from b08c278 to e5ff02b Compare April 17, 2018 00:29

dylanjw force-pushed the filtering-middleware branch from e5ff02b to b77418e Compare April 17, 2018 00:39

dylanjw force-pushed the filtering-middleware branch from b0d02e1 to 1897f12 Compare May 16, 2018 23:11

dylanjw mentioned this pull request Jun 22, 2018

"filter not found" in Web3.py 4.2.0 #923

Closed

dylanjw force-pushed the filtering-middleware branch 2 times, most recently from bf6fde1 to 0e2df37 Compare July 25, 2018 22:39

dylanjw force-pushed the filtering-middleware branch 4 times, most recently from 6e061e2 to aba52df Compare August 7, 2018 20:44

dylanjw mentioned this pull request Aug 30, 2018

HTTPError at /testing/ 405 Client Error: Method Not Allowed for url: #1036

Closed

dylanjw force-pushed the filtering-middleware branch from aba52df to b7b4567 Compare September 18, 2018 18:02

Pass through methods when filter not created by middleware

93ccd48

dylanjw force-pushed the filtering-middleware branch from 051723a to 93ccd48 Compare September 23, 2018 22:13

dylanjw added 2 commits September 23, 2018 15:39

Increase block request range

d62f7c3

Wait for matching transactions

cd581d6

dylanjw force-pushed the filtering-middleware branch from b2441fc to cd581d6 Compare September 23, 2018 23:03

dylanjw added 4 commits September 25, 2018 15:22

Fix bug in block_ranges

70a3600

Also added snapshot/revert to deal with hypothesis issue

Use w3 var name for Web3 instance

6fa2f96

Handle case where blocks havent caught up with filter params

77817c1

Test filters with bounded block range

b0677e7

pipermerriam assigned carver Sep 26, 2018

carver approved these changes Sep 26, 2018

View reviewed changes

jasonrhaas mentioned this pull request Sep 27, 2018

Filters not supported on Infura gitcoinco/gitcoin-erc721#129

Closed

Make review request changes

03452cc

dylanjw force-pushed the filtering-middleware branch from 9b4cb26 to 03452cc Compare September 27, 2018 18:24

Add local_filter_middleware to docs

ce0d947

dylanjw merged commit be410b2 into ethereum:master Sep 27, 2018

dylanjw mentioned this pull request Sep 27, 2018

Filters that don't rely on server state #551

Closed

jgeary mentioned this pull request Feb 15, 2019

local_filter_middleware example doesn't work #1244

Closed

derekpierre mentioned this pull request Sep 23, 2020

Event filters can sometimes disappear and cause 'filter not found' error nucypher/nucypher#2291

Closed

etam mentioned this pull request Feb 10, 2021

GETH - filter not found golemfactory/yagna-triage#60

Closed

		return _start, _end


		def unload_latest_blocks(web3, fromBlock, toBlock):

		yield web3.eth.getBlock(block_number).hash


		def filter_middleware(make_request, web3):

		))


		@pytest.fixture(scope='function')

node independent filter middleware #732

node independent filter middleware #732

Conversation

dylanjw commented Apr 1, 2018 • edited Loading

What was wrong?

How was it fixed?

Cute Animal Picture

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dylanjw Apr 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dylanjw commented Apr 3, 2018

pipermerriam commented Apr 3, 2018

carver commented Apr 3, 2018

dylanjw commented Apr 5, 2018

pipermerriam left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pipermerriam left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dylanjw commented Apr 17, 2018 • edited Loading

pipermerriam commented Apr 17, 2018 • edited Loading

dylanjw commented May 16, 2018

dylanjw commented Sep 21, 2018

dylanjw commented Sep 23, 2018 • edited Loading

dylanjw commented Sep 24, 2018

dylanjw commented Sep 24, 2018

carver commented Sep 25, 2018 • edited Loading

carver commented Sep 25, 2018

carver commented Sep 25, 2018

dylanjw commented Sep 25, 2018 • edited Loading

dylanjw commented Sep 26, 2018 • edited Loading

pipermerriam commented Sep 26, 2018

carver left a comment

Choose a reason for hiding this comment

carver Sep 26, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dylanjw commented Apr 1, 2018 •

edited

Loading

dylanjw Apr 2, 2018 •

edited

Loading

dylanjw commented Apr 17, 2018 •

edited

Loading

pipermerriam commented Apr 17, 2018 •

edited

Loading

dylanjw commented Sep 23, 2018 •

edited

Loading

carver commented Sep 25, 2018 •

edited

Loading

dylanjw commented Sep 25, 2018 •

edited

Loading

dylanjw commented Sep 26, 2018 •

edited

Loading

carver Sep 26, 2018 •

edited

Loading