Sprint #13 - 2019-06-21

Sprint metrics

  • Story Points: 57

  • Story Points for Code Freeze: 85

  • Story Points for Technical Go-live: 409

User stories

RLAU-68 - Separate submitAtom and subscribeAtom APIs

Story
Criteria

Update the APIs so a user is able to listen for updates about an atom even if it's not the submitter.

  • Contributor: Josh

  • Component: core

As a node API user, I want to be able to listen for updates about an atom even if I'm not the submitter, So that I can check for the progress of my atom across the network

Atom Status States: DOES_NOT_EXIST PENDING_CM_VERIFICATION PENDING_DEPENDENCY_VERIFICATION PENDING_MISSING_DEPENDENCY CONFLICTED STORED

Acceptance criteria

1. Submit valid atom

Given that I'm an API client When I submit a valid atom to a node Then I should receive a response when the node has queued the atom

2. Submit invalid atom

Given that I'm an API client When I submit an improperly structured atom to a node Then I should receive a response with the error

3. Atom status stream

Given that I'm a streaming API client that's connected to a node and subscribed to updates for the AID of a valid atom When I submit the atom Then I should see status update notifications for the atom

4. Atom get status

Given that I'm an API client When I request for an atom status by AID Then I should receive a response with it's current status

RLAU-1123 - Let user search for transactions

Story
Criteria

Enable Bitcoin transaction search in the 1M TPS Explorer.

  • Contributor: László

  • Component: explorer

As an end user, I would like to retrieve all processed transactions for a particular Bitcoin address, So that I can verify that the transactions have indeed been processed.

Acceptance criteria

Scenario 1: See Bitcoin address field

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test or the test has just finished, When the page is fully loaded, Then I can see an empty "Bitcoin address" input field and a disabled "Watch" button.

Scenario 2: Query Bitcoin address that has transactions

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test or the test has just finished, And I have entered a valid address in the "Bitcoin address" field, When I click the "Watch" button, Then a progress spinner will be shown and after some time a list of transactions will appear below the input field, showing the transacted amount of BTC and the date/time of each transaction.

Scenario 3: Query invalid Bitcoin address

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test or the test has just finished, And I have entered an invalid address in the "Bitcoin address" field, When I click the "Watch" button, Then nothing happens and the "Watch" button remains disabled.

Scenario 4: Query Bitcoin address that has no transactions yet

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test or the test has just finished, And I have entered a valid address in the "Bitcoin address" field, When I click the "Watch" button, Then a progress spinner will be shown and after some time a notification is shown explaining that there aren't any processed transactions for the given address yet.

RLAU-1124 - Let user see metrics data

Story
Criteria

Display data metrics in the 1M TPS Explorer.

  • Contributor: László

  • Component: explorer

As an end user, I would like to see an indication of the Bitcoin data is being processed by the Radix ledger, So that I can get an understanding of how far the test has progressed.

Acceptance criteria

Scenario 1: Show peak TPS

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished and the node network has been destroyed, When the page is fully loaded, Then I can see the peak TPS value measured during the test.

Scenario 2: Show average TPS

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished and the node network has been destroyed, When the page is fully loaded, Then I can see the average TPS measured during the test.

Scenario 3: Show next test date/time

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished and the node network has been destroyed, When the page is fully loaded, Then I can see the date and time when the next test is scheduled.

"During Test" Page

Scenario 4: See a progress bar

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test, When the page is fully loaded, Then I can see a progress bar that grows as the test proceeds.

Scenario 5: See current TPS

Given that I have pointed my browser to https://1m.radixdlt.com, And there is an ongoing test, When the page is fully loaded, Then I can see a calculated transactions-per-second metric.

"After Test" Page

Scenario 6: Show test duration

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished, When the page is fully loaded, Then I can see the time the test took to execute.

Scenario 7: Show peak TPS

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished, When the page is fully loaded, Then I can see the peak TPS value measured during the test.

Scenario 8: Show average TPS

Given that I have pointed my browser to https://1m.radixdlt.com, And the test has finished, When the page is fully loaded, Then I can see the average TPS measured during the test.

RLAU-1214 - Expose metrics REST API endpoint

Story
Criteria

Expose a REST API endpoint to get the last calculated throughput metrics for the test network.

  • Contributor: László

  • Component: explorer

As a web app, I want to get the last calculated throughput metrics for the test network from a cached web service, So that I and all other instances of me don't put unnecessary load on the network nodes.

API endpoint

GET /api/metrics

Acceptance criteria

Scenario 1: Issue valid API request

Given that the service is up and running, When I send an HTTP GET request to the endpoint, Then an HTTP 200 response with a valid JSON body is returned.

Example JSON response:

{
"type": "metrics",
"meta": {
"testState": "FINISHED",
"testStart": 0123456789,
"testStop": 9876543210,
"progressMax": 410000000
},
"data": {
"spotTps": 2000000,
"peakTps": 2100000,
"averageTps": 1980000,
"progress": 409990000
}
}

Scenario 2: Invalid HTTP method

Given that the service is up and running, When I send an HTTP request with a method other than GET to the endpoint, Then an HTTP 403 response is returned that informs me about only GET requests being served.

RLAU-1217 - Expose query REST API endpoint

Story
Criteria

Expose a REST API endpoint to query processed transactions for a particular Bitcoin address.

  • Contributor: László

  • Component: explorer

As a web app, I want to query processed transactions for a particular Bitcoin address from a cached web service, So that I and all other instances of me don't put unnecessary load on the network nodes.

API endpoint

GET /api/transactions/:bitcoin_address?page=:index

The page query parameter is optional and defaults to 0 if omitted.

Definition of a valid Bitcoin address

  • length: 25 bytes

  • byte[0]: version, 1 or 3

  • byte[1-20]: data, RIPEMD-160 digest

  • byte[21-24]: checksum, double SHA-256 digest of bytes[0-20]

Reference: https://en.bitcoin.it/wiki/Address Example: http://rosettacode.org/wiki/Bitcoin/address_validation

Acceptance criteria

Scenario 1: Issue valid API request

Given that the service is up and running, When I send an HTTP GET request to the endpoint, Then an HTTP 200 response with a valid, paged JSON body is returned.

Example JSON response:

{
"type": "transactions",
"meta": {
"page": 1
},
"data": [
{
"amount", 0.00000012,
"bitcoinTransactionId": "abc123",
"bitcoinBlockTimestamp": 1234567890
}
]
}

Scenario 2: Invalid HTTP method

Given that the service is up and running, When I send an HTTP request with a method other than GET to the endpoint, Then an HTTP 405 response is returned that informs me about only GET requests being served.

Scenario 3: Unknown query parameters

Given that the service is up and running, When I send an HTTP GET request with unknown query parameters to the endpoint, Then all invalid query parameters are silently ignored.

Scenario 4: Missing query parameters

Given that the service is up and running, When I send an HTTP GET request with a missing page query parameter to the endpoint, Then the first page of transactions (for that Bitcoin address) is returned.

Scenario 5: Invalid page query parameter

Given that the service is up and running, When I send an HTTP GET request with a negative or non-integer page query parameter to the endpoint, Then an HTTP 400 response is returned.

Scenario 6: Out of range page query parameter

Given that the service is up and running, When I send an HTTP GET request with a too large page query parameter to the endpoint, Then an empty list of transactions is returned.

Scenario 7: Invalid Bitcoin address query parameter

Given that the service is up and running, When I send an HTTP GET request with an invalid bitcoin_address fragment to the endpoint, Then an HTTP 400 response is returned.