2021-02-04 19:15:23 +01:00
|
|
|
import nock from 'nock';
|
|
|
|
import sinon from 'sinon';
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-28 21:53:59 +02:00
|
|
|
import { getStorageItem, setStorageItem } from './storage-helpers';
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-28 21:53:59 +02:00
|
|
|
jest.mock('./storage-helpers.js', () => ({
|
2021-04-15 20:01:46 +02:00
|
|
|
getStorageItem: jest.fn(),
|
|
|
|
setStorageItem: jest.fn(),
|
|
|
|
}));
|
|
|
|
|
|
|
|
const fetchWithCache = require('./fetch-with-cache').default;
|
|
|
|
|
|
|
|
describe('Fetch with cache', () => {
|
|
|
|
afterEach(() => {
|
2021-02-04 19:15:23 +01:00
|
|
|
sinon.restore();
|
|
|
|
nock.cleanAll();
|
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('fetches a url', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 1}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2020-11-03 00:41:28 +01:00
|
|
|
const response = await fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/price',
|
2021-02-04 19:15:23 +01:00
|
|
|
);
|
2021-04-15 20:01:46 +02:00
|
|
|
expect(response).toStrictEqual({
|
2019-09-04 21:10:23 +02:00
|
|
|
average: 1,
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('returns cached response', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 2}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
getStorageItem.mockReturnValueOnce({
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
cachedResponse: { average: 1 },
|
|
|
|
cachedTime: Date.now(),
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2020-11-03 00:41:28 +01:00
|
|
|
const response = await fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/price',
|
2021-02-04 19:15:23 +01:00
|
|
|
);
|
2021-04-15 20:01:46 +02:00
|
|
|
expect(response).toStrictEqual({
|
2019-09-04 21:10:23 +02:00
|
|
|
average: 1,
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('fetches URL again after cache refresh time has passed', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 3}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
getStorageItem.mockReturnValueOnce({
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
cachedResponse: { average: 1 },
|
|
|
|
cachedTime: Date.now() - 1000,
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2020-11-03 00:41:28 +01:00
|
|
|
const response = await fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/price',
|
|
|
|
{},
|
|
|
|
{ cacheRefreshTime: 123 },
|
2021-02-04 19:15:23 +01:00
|
|
|
);
|
2021-04-15 20:01:46 +02:00
|
|
|
expect(response).toStrictEqual({
|
2019-09-04 21:10:23 +02:00
|
|
|
average: 3,
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('should abort the request when the custom timeout is hit', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
|
|
|
.delay(100)
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 4}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
await expect(() =>
|
|
|
|
fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/price',
|
|
|
|
{},
|
|
|
|
{ timeout: 20 },
|
|
|
|
),
|
|
|
|
).rejects.toThrow({ name: 'AbortError', message: 'Aborted' });
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('throws when the response is unsuccessful', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(500, '{"average": 6}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
await expect(() =>
|
2020-11-03 00:41:28 +01:00
|
|
|
fetchWithCache('https://fetchwithcache.metamask.io/price'),
|
2021-04-15 20:01:46 +02:00
|
|
|
).rejects.toThrow('');
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('throws when a POST request is attempted', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.post('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 7}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
await expect(() =>
|
2020-11-03 00:41:28 +01:00
|
|
|
fetchWithCache('https://fetchwithcache.metamask.io/price', {
|
|
|
|
method: 'POST',
|
|
|
|
}),
|
2021-04-15 20:01:46 +02:00
|
|
|
).rejects.toThrow('');
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('throws when the request has a truthy body', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 8}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
await expect(() =>
|
2020-11-03 00:41:28 +01:00
|
|
|
fetchWithCache('https://fetchwithcache.metamask.io/price', { body: 1 }),
|
2021-04-15 20:01:46 +02:00
|
|
|
).rejects.toThrow('');
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('throws when the request has an invalid Content-Type header', async () => {
|
2019-09-04 21:10:23 +02:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/price')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 9}');
|
2019-09-04 21:10:23 +02:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
await expect(() =>
|
|
|
|
fetchWithCache('https://fetchwithcache.metamask.io/price', {
|
|
|
|
headers: { 'Content-Type': 'text/plain' },
|
|
|
|
}),
|
|
|
|
).rejects.toThrow({
|
|
|
|
message: 'fetchWithCache only supports JSON responses',
|
|
|
|
});
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
it('should correctly cache responses from interwoven requests', async () => {
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/foo')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 9}');
|
2021-04-15 20:01:46 +02:00
|
|
|
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
nock('https://fetchwithcache.metamask.io')
|
|
|
|
.get('/bar')
|
2021-02-04 19:15:23 +01:00
|
|
|
.reply(200, '{"average": 9}');
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
|
2021-02-04 19:15:23 +01:00
|
|
|
const testCache = {};
|
2021-04-15 20:01:46 +02:00
|
|
|
getStorageItem.mockImplementation((key) => testCache[key]);
|
|
|
|
setStorageItem.mockImplementation((key, value) => {
|
2021-02-04 19:15:23 +01:00
|
|
|
testCache[key] = value;
|
|
|
|
});
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
|
|
|
|
await Promise.all([
|
|
|
|
fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/foo',
|
|
|
|
{},
|
|
|
|
{ cacheRefreshTime: 123 },
|
|
|
|
),
|
|
|
|
fetchWithCache(
|
|
|
|
'https://fetchwithcache.metamask.io/bar',
|
|
|
|
{},
|
|
|
|
{ cacheRefreshTime: 123 },
|
|
|
|
),
|
2021-02-04 19:15:23 +01:00
|
|
|
]);
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
|
2021-04-15 20:01:46 +02:00
|
|
|
expect(
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
testCache['cachedFetch:https://fetchwithcache.metamask.io/foo']
|
|
|
|
.cachedResponse,
|
2021-04-15 20:01:46 +02:00
|
|
|
).toStrictEqual({ average: 9 });
|
|
|
|
expect(
|
Fix `fetch-with-cache` handling of interwoven requests (#10079)
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
2020-12-15 21:21:13 +01:00
|
|
|
testCache['cachedFetch:https://fetchwithcache.metamask.io/bar']
|
|
|
|
.cachedResponse,
|
2021-04-15 20:01:46 +02:00
|
|
|
).toStrictEqual({ average: 9 });
|
2021-02-04 19:15:23 +01:00
|
|
|
});
|
|
|
|
});
|