The rewards was distributed to non-registered stake address

Mainnet, db-sync 6.0.1, stake address stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
registration history
SELECT stake_registration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_registration ON stake_registration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_registration.tx_id
LEFT JOIN block ON block.id = tx.block_id
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      208 | 2020-08-01 07:45:51
   38278 |      233 | 2020-12-01 22:31:13
(2 rows)

de-registration history
SELECT stake_deregistration.addr_id, block.epoch_no, block.time
FROM stake_address
LEFT JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
LEFT JOIN tx ON tx.id = stake_deregistration.tx_id
LEFT JOIN block ON block.id = tx.block_id
WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';

 addr_id | epoch_no |        time
---------+----------+---------------------
   38278 |      232 | 2020-12-01 18:25:59
(1 row)

as we can see, the address has not been registered at the end of the 232 epoch, and the rewards for the epoch 231 should not be distributed to this address, but
SELECT reward.*, block.epoch_no AS block_epoch_no, block.time
FROM reward
LEFT JOIN block ON block.id = reward.block_id
WHERE reward.addr_id = 38278 AND reward.epoch_no = 231;

   id    | addr_id |  amount   | epoch_no | pool_id | block_id | block_epoch_no |        time
---------+---------+-----------+----------+---------+----------+----------------+---------------------
 1041508 |   38278 | 192969560 |      231 |     144 |  5023676 |            233 | 2020-12-01 21:44:51
(1 row)

:facepalm:
Looked at this for a while and then suddenly realized that the first query does not show what @dmitrystas thinks it shows. By joining on tx.id = stake_registration.tx_id and then getting the block.epoch_no from the transaction, you get the epoch that the stake registration/deregistration occurs, but not when it is actually active.
For most operations related to staking, actions (like registrations, increases in amount staked etc) that occur in epoch N become active in epoch N + 2 .
That means the first query should actually be:
cexplorer=# SELECT stake_registration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address
              INNER JOIN stake_registration ON stake_registration.addr_id = stake_address.id
              INNER JOIN tx ON tx.id = stake_registration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
addr_id | epoch_no |        time
---------+----------+---------------------
   38266 |      210 | 2020-08-01 07:45:51
   38266 |      235 | 2020-12-01 22:31:13

and the second:
cexplorer=# SELECT stake_deregistration.addr_id, block.epoch_no + 2 as epoch_no, block.time FROM stake_address
              INNER JOIN stake_deregistration ON stake_deregistration.addr_id = stake_address.id
              INNER JOIN tx ON tx.id = stake_deregistration.tx_id INNER JOIN block ON block.id = tx.block_id
              WHERE stake_address.view = 'stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86';
 addr_id | epoch_no |        time
---------+----------+---------------------
   38266 |      234 | 2020-12-01 18:25:59

@dmitrystas Does that all add up? Would it help adding an extra active_epoch_no column to the stake_registration and stake_deregistration tables like I have the the delegation table?

@erikd Good day. That is original issue https://github.com/Emurgo/yoroi-frontend/issues/1832#issue-754776885
Maybe could be usefull

Yoroi still shows reward balance 192ADA.

There are at least two possibilities;

there is a db-sync bug
there is a Yoroi bug

I only deal with db-sync. That means that problems need to be presented to me as SQL queries not as information from Yoroi.
Is stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 the stake key of interest here?

@erikd yes the stake key is stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86
Note that not only Yoroi HAS THAT BUG but Adalite.io and adastat.net
Theese DO NOT HAVE that bug: cardanoscan.io and adawallet.io

If some online wallets have this but and others do not, and all of these depend on db-sync then the problem is very unlikey to be in db-sync.

@erikd But adawallet.io does not use db-sync and shows correct reward balance and it let me withdraw last rewards

Again that suggests this is a Yoroi bug, not a db-sync bug.

Exodus encountered this bug as well.

Exodus encountered this bug as well.

This is definitely a cardano-db-sync bug and not a Yoroi bug given how this affects not just Yoroi but multiple other users of cardano-db-sync as well. cardanoscan and adawallet both do not use cardano-db-sync which is why they aren't affected.
What cardano-db-sync reports
Here is the SQL query that gives the reward history for the address provided by @IlyaSofronov
select stake_address.hash_raw as "stakeAddress"
      , "totalReward".*

from stake_address

left outer join (
  SELECT addr_id, amount, epoch_no
  FROM reward
) as "totalReward" on stake_address.id = "totalReward".addr_id

where encode(stake_address.hash_raw, 'hex') = 'e1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'

and gives the following result
\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235

Note: Sum of these rows is<PHONE_NUMBER>
Note: not shown here is epoch 236 in which 102078 ADA was earned (you can confirm this with an explorer and we verify this with a fullnode later in this post
Note<PHONE_NUMBER> + 102078  = 3,765,004,402
Current (incorrect) state from our backend
{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

You can see our backend returns the sum of the db-sync rows for the rewards value (will explain why this is the issue later)
You can also verify the withdrawals amount is correct by summing up the values on cardanoscan which we know isn't affected by this bug.
remainingAmount is just rewards - withdrawals
Registration history for the wallet
By looking at the history of this staking key, you can see:

It was deregistered on epoch 232
It was re-registered on epoch 233

Current state from cardano-node
According to my cardano-node instance, this is the current value inside the staking address
[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

So you can see that according to the node, the balance of the wallet is epoch 235 + epoch 236 (100702 + 102078 = 202780)
So what is the issue?
By looking at cardanoscan we can see the full withdrawal history of the wallet. Let's see what each withdrawal corresponds to:

Epoch withdrawn
Amount withdrawn
db-sync epoch rows included

228
2601.373144
211, 212, ..., 225, 226

230
371.141369
227, 228

232
317.641570
229, 230

234
135.711434
232

235
145.964545
233

HOWEVER You can see epoch 231 in cardano-db-sync (192969560) is not included in any of these!
Sure enough, if you look at our backend response, "remainingAmount": "193172340", and you do 193172340 - 192969560 you can 202780 which is the expected result from our fullnode!
Conclusion
Based on my investigation, it seems cardano-db-sync includes row 231 in the reward history result even though it shouldn't.

This is definitely a cardano-db-sync bug and not a Yoroi bug given how this affects not just Yoroi but multiple other users of cardano-db-sync as well. cardanoscan and adawallet both do not use cardano-db-sync which is why they aren't affected.
What cardano-db-sync reports
Here is the SQL query that gives the reward history for the address provided by @IlyaSofronov
select stake_address.hash_raw as "stakeAddress"
      , "totalReward".*

from stake_address

left outer join (
  SELECT addr_id, amount, epoch_no
  FROM reward
) as "totalReward" on stake_address.id = "totalReward".addr_id

where encode(stake_address.hash_raw, 'hex') = 'e1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'

and gives the following result
\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235

Note: Sum of these rows is<PHONE_NUMBER>
Note: not shown here is epoch 236 in which 102078 ADA was earned (you can confirm this with an explorer and we verify this with a fullnode later in this post
Note<PHONE_NUMBER> + 102078  = 3,765,004,402
Current (incorrect) state from our backend
{
    "remainingAmount": "193172340",
    "rewards": "3765004402",
    "withdrawals": "3571832062",
}

You can see our backend returns the sum of the db-sync rows for the rewards value (will explain why this is the issue later)
You can also verify the withdrawals amount is correct by summing up the values on cardanoscan which we know isn't affected by this bug.
remainingAmount is just rewards - withdrawals
Registration history for the wallet
By looking at the history of this staking key, you can see:

It was deregistered on epoch 232
It was re-registered on epoch 233

Current state from cardano-node
According to my cardano-node instance, this is the current value inside the staking address
[
    {
        "address": "stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86",
        "delegation": "pool1kkfkdces5mdcyc9dn2hgg3463jggjvw3h89nejjarkz25uavaqu",
        "rewardAccountBalance": 202780
    }
]

So you can see that according to the node, the balance of the wallet is epoch 235 + epoch 236 (100702 + 102078 = 202780)
So what is the issue?
By looking at cardanoscan we can see the full withdrawal history of the wallet. Let's see what each withdrawal corresponds to:

Epoch withdrawn
Amount withdrawn
db-sync epoch rows included

228
2601.373144
211, 212, ..., 225, 226

230
371.141369
227, 228

232
317.641570
229, 230

234
135.711434
232

235
145.964545
233

HOWEVER You can see epoch 231 in cardano-db-sync (192969560) is not included in any of these!
Sure enough, if you look at our backend response, "remainingAmount": "193172340", and you do 193172340 - 192969560 you can 202780 which is the expected result from our fullnode!
Conclusion
Based on my investigation, it seems cardano-db-sync includes row 231 in the reward history result even though it shouldn't.

I simplified the first query and validated that I get same results (I did).

Current (incorrect) state from our backend

I would prefer to get all information from a single source so:
cexplorer=# select sum (amount) from stake_address
        left outer join (SELECT addr_id, amount, epoch_no
        FROM reward) as "totalReward" on stake_address.id = "totalReward".addr_id
        where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
    sum
------------
<PHONE_NUMBER>

and:
cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum
------------
<PHONE_NUMBER>

both of which agree with your figures.
Interestingly<PHONE_NUMBER> + 192969560 + 202780 -<PHONE_NUMBER> where<PHONE_NUMBER> is the withdrawal sum and<PHONE_NUMBER> is the reward sum. The other values are; 202780 which is your figure for the reward balance after withdrawals and 192969560 is the rewards for epoch 231.
cexplorer=# select stake_address.view as "stakeAddress", "totalReward".* from stake_address
     left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'
     and epoch_no = 231 ;
                        stakeAddress                         | addr_id |  amount   | epoch_no
-------------------------------------------------------------+---------+-----------+----------
 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |   38266 | 192969560 |      231

So is that reward for epoch 231 (which db-sync simply pulls out of the ledger state and inserts in the database with zero extra processing) correct? Lets look at the stake registration history for that stake address:
cexplorer=# select stake_address.hash_raw, stake_registration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no
    from stake_registration inner join stake_address on stake_registration.addr_id = stake_address.id
    inner join tx on tx.id = stake_registration.tx_id inner join block on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 2449294 |         208 |             210
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3103705 |         233 |             235
(2 rows)

cexplorer=# select stake_address.hash_raw, stake_deregistration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no from stake_deregistration
    inner join stake_address on stake_deregistration.addr_id = stake_address.id
    inner join tx on tx.id = stake_deregistration.tx_id inner join block
    on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3101670 |         232 |             234

Note that for both the registration and the deregistration i have included the tx_id (the id of the tx that contained the registration/deregistration), tx_epoch_no  (the epoch in which the tx was included) and active_epoch_no (the epoch in which the registration/deregistration becomes active).
Looking at the active epoch numbers, the stake registration should have been active in epochs [210 .. 233] and [234 ..] .
Therefore I think your conclusion:

Based on my investigation, it seems cardano-db-sync includes row 231 in the reward history result even though it shouldn't.

is incorrect, that stake address *should have rewards for epoch 231.
Furthermore, I believe that your comment:

Current (incorrect) state from our backend
{
"remainingAmount": "193172340",
"rewards": "3765004402",
"withdrawals": "3571832062",
}

is also incorrect. The difference between the rewards value and the withdrawal value is the current reward balance/

I simplified the first query and validated that I get same results (I did).

Current (incorrect) state from our backend

I would prefer to get all information from a single source so:
cexplorer=# select sum (amount) from stake_address
        left outer join (SELECT addr_id, amount, epoch_no
        FROM reward) as "totalReward" on stake_address.id = "totalReward".addr_id
        where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
    sum
------------
<PHONE_NUMBER>

and:
cexplorer=# select sum (amount) from withdrawal where addr_id = 38266;
    sum
------------
<PHONE_NUMBER>

both of which agree with your figures.
Interestingly<PHONE_NUMBER> + 192969560 + 202780 -<PHONE_NUMBER> where<PHONE_NUMBER> is the withdrawal sum and<PHONE_NUMBER> is the reward sum. The other values are; 202780 which is your figure for the reward balance after withdrawals and 192969560 is the rewards for epoch 231.
cexplorer=# select stake_address.view as "stakeAddress", "totalReward".* from stake_address
     left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde'
     and epoch_no = 231 ;
                        stakeAddress                         | addr_id |  amount   | epoch_no
-------------------------------------------------------------+---------+-----------+----------
 stake1u838ke609j09ezrgj5nwnplvc7g3cq62pa2n9z0x6w3clhsagtp86 |   38266 | 192969560 |      231

So is that reward for epoch 231 (which db-sync simply pulls out of the ledger state and inserts in the database with zero extra processing) correct? Lets look at the stake registration history for that stake address:
cexplorer=# select stake_address.hash_raw, stake_registration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no
    from stake_registration inner join stake_address on stake_registration.addr_id = stake_address.id
    inner join tx on tx.id = stake_registration.tx_id inner join block on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 2449294 |         208 |             210
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3103705 |         233 |             235
(2 rows)

cexplorer=# select stake_address.hash_raw, stake_deregistration.tx_id, block.epoch_no
    as tx_epoch_no, (block.epoch_no + 2) as active_epoch_no from stake_deregistration
    inner join stake_address on stake_deregistration.addr_id = stake_address.id
    inner join tx on tx.id = stake_deregistration.tx_id inner join block
    on tx.block_id = block.id
    where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                           hash_raw                           |  tx_id  | tx_epoch_no | active_epoch_no
--------------------------------------------------------------+---------+-------------+-----------------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde | 3101670 |         232 |             234

Note that for both the registration and the deregistration i have included the tx_id (the id of the tx that contained the registration/deregistration), tx_epoch_no  (the epoch in which the tx was included) and active_epoch_no (the epoch in which the registration/deregistration becomes active).
Looking at the active epoch numbers, the stake registration should have been active in epochs [210 .. 233] and [234 ..] .
Therefore I think your conclusion:

Based on my investigation, it seems cardano-db-sync includes row 231 in the reward history result even though it shouldn't.

is incorrect, that stake address *should have rewards for epoch 231.
Furthermore, I believe that your comment:

Current (incorrect) state from our backend
{
"remainingAmount": "193172340",
"rewards": "3765004402",
"withdrawals": "3571832062",
}

is also incorrect. The difference between the rewards value and the withdrawal value is the current reward balance/

is actually correct. The difference between the rewards value and the withdrawal value is the current unwithdrawn reward balance.

That can't be the case because we know the node returns 202780 as the reward balance for the account and not 193172340

Ie, there are rewards for every epoch except 234.

You should expect two epochs to be missing:

The epoch where the rewards were sent back to the reserves because they didn't have their stake key registered
The epoch representing the 1 epoch gap between when they deregistered their key and when they re-registered

The missing 234 epoch corresponds to (2), and I believe 231 corresponds to (1). (since 231 means it should be visible in the user's wallet at epoch 233 which is precisely the epoch we expect to have been forfeited for (1))

is actually correct. The difference between the rewards value and the withdrawal value is the current unwithdrawn reward balance.

That can't be the case because we know the node returns 202780 as the reward balance for the account and not 193172340

Ie, there are rewards for every epoch except 234.

You should expect two epochs to be missing:

The epoch where the rewards were sent back to the reserves because they didn't have their stake key registered
The epoch representing the 1 epoch gap between when they deregistered their key and when they re-registered

The missing 234 epoch corresponds to (2), and I believe 231 corresponds to (1). (since 231 means it should be visible in the user's wallet at epoch 233 which is precisely the epoch we expect to have been forfeited for (1))

You should expect two epochs to be missing:

Why? According to the operations on this stake address:

operation
tx_epoch_no
active_epoch_no

registraion
208
210

deregistraion
232
234

registraion
233
235

it was only deregistered for a single epoch (234) and received no rewards for that epoch.
Why would there be two epoch's without rewards? I am pretty sure the two cases you mention are actually the same thing and hence only one epoch goes without a reward.

You should expect two epochs to be missing:

Why? According to the operations on this stake address:

operation
tx_epoch_no
active_epoch_no

registraion
208
210

deregistraion
232
234

registraion
233
235

it was only deregistered for a single epoch (234) and received no rewards for that epoch.
Why would there be two epoch's without rewards? I am pretty sure the two cases you mention are actually the same thing and hence only one epoch goes without a reward.

@SebastienGllmt in Slack said:

deregistration is special in that it takes place right away, not in 2 epochs

If deregistration takes pace immediately, this one happened in tx_epoch_no == 232 so rewards for epochs [231..234]  would all be lost, not just the rewards for 231.

@SebastienGllmt in Slack said:

deregistration is special in that it takes place right away, not in 2 epochs

If deregistration takes pace immediately, this one happened in tx_epoch_no == 232 so rewards for epochs [231..234]  would all be lost, not just the rewards for 231.

@SebastienGllmt 's explanation is consistent with the ledger rules.
It's a bit philosophical "when" a stake key is deregistered, but I would phrase it like this: deregistration takes place immediately, but rewards are delayed. If a key is de-registered in epoch e, then it will receive rewards on the e / e+1 boundary (coming from the snapshot taken on the e-2 / e -1 boundary) and it will also receive rewards on the e+1 / e+2 boundary (coming from the snapshot taken on the e-1 / e  boundary).

@SebastienGllmt 's explanation is consistent with the ledger rules.
It's a bit philosophical "when" a stake key is deregistered, but I would phrase it like this: deregistration takes place immediately, but rewards are delayed. If a key is de-registered in epoch e, then it will receive rewards on the e / e+1 boundary (coming from the snapshot taken on the e-2 / e -1 boundary) and it will also receive rewards on the e+1 / e+2 boundary (coming from the snapshot taken on the e-1 / e  boundary).

This sounds like we have some confusion with nomenclature.
From the POV of dbs-ync: :

tx_epoch_no : the epoch containing the transactions of the registration/deregistration certififcate.
active_epoch_no : basically tx_epoch_no + 2, the epoch in which changes to the stake address become active.
epoch_no in reward table: the actual epoch in which rewards were earned.

This sounds like we have some confusion with nomenclature.
From the POV of dbs-ync: :

tx_epoch_no : the epoch containing the transactions of the registration/deregistration certififcate.
active_epoch_no : basically tx_epoch_no + 2, the epoch in which changes to the stake address become active.
epoch_no in reward table: the actual epoch in which rewards were earned.

if the stake credential was in a deregistration certificate from a transaction in epoch 232, then it would not be included in the snapshot taken on the 232/233 boundary. this means that it would not be a part of the reward update that is handed out on the 235/236 boundary. which, in @erikd 's terms, is the 234 rewards.

if the stake credential was in a deregistration certificate from a transaction in epoch 232, then it would not be included in the snapshot taken on the 232/233 boundary. this means that it would not be a part of the reward update that is handed out on the 235/236 boundary. which, in @erikd 's terms, is the 234 rewards.

it's worth noting that things like "de-registered when", "rewards at", and "active when", etc, can be confusing if we aren't really clear. so it's not clear to me who all I am agreeing with :)

it's worth noting that things like "de-registered when", "rewards at", and "active when", etc, can be confusing if we aren't really clear. so it's not clear to me who all I am agreeing with :)

Since there seems to be confusion, I made a picture that shows the two expected missing epochs (db-sync 231 and db-sync 234)

Since there seems to be confusion, I made a picture that shows the two expected missing epochs (db-sync 231 and db-sync 234)

I made a picture that shows the two expected missing epochs (db-sync 231 and db-sync 234)

But the actual rewards as reported by db-sync are:
cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

and only epoch 234 has no rewards. db-sync gets the contents of this table from ledger-state and the only thing db-sync adds is the epoch_no column.
Your diagram does not match this table, so your diagram is likely incorrect. There may also be a bug in the node but I would prefer to only deal with a single variable (db-sync) for now.

I made a picture that shows the two expected missing epochs (db-sync 231 and db-sync 234)

But the actual rewards as reported by db-sync are:
cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 192969560 |      231
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
(25 rows)

and only epoch 234 has no rewards. db-sync gets the contents of this table from ledger-state and the only thing db-sync adds is the epoch_no column.
Your diagram does not match this table, so your diagram is likely incorrect. There may also be a bug in the node but I would prefer to only deal with a single variable (db-sync) for now.

In your diagram you have "rewards delivered" crossed out for epoch 233, and both Jared and I think that is incorrect and that rewards should be delivered (because they are based on the snapshot at the start of epoch 231, not the current state of the chain).

In your diagram you have "rewards delivered" crossed out for epoch 233, and both Jared and I think that is incorrect and that rewards should be delivered (because they are based on the snapshot at the start of epoch 231, not the current state of the chain).

@SebastienGllmt says:

I think the confusion comes from the fact that 231 may not technically be missing -- it could be the ledger state just considers it distributed to the reserves instead of the user.

But the rewards table shows the reward being distributed to the stake address. If it was distributed to reserves, it would not be in this table.

@SebastienGllmt says:

I think the confusion comes from the fact that 231 may not technically be missing -- it could be the ledger state just considers it distributed to the reserves instead of the user.

But the rewards table shows the reward being distributed to the stake address. If it was distributed to reserves, it would not be in this table.

I was wrong when I said:

moreover, if the (re)registration certificate landed in a transaction in epoch 233, then this would be the only reward update that it would miss out on.

In fact, @SebastienGllmt was exactly right when he said:

You should expect two epochs to be missing:

The epoch where the rewards were sent back to the reserves because they didn't have their stake key registered
The epoch representing the 1 epoch gap between when they deregistered their key and when they re-registered

By not being registered on the 232/233 epoch boundary, the stake credential both:

does not get the rewards from the update being applied on the 232/233 boundary, and
is not included in the stake distribution snapshot taken on the 232/233 boundary (so that it does not get the rewards handed out on the 235/236 boundary).

I can guess how db-sync is reporting rewards being handed out on the 232/233 boundary (which is really just @SebastienGllmt 's guess :) ). The ledger state cannot know until the last moment before the epoch boundary which credentials are still registered. We return rewards for unregistered credentials to the reserves. (See Figure 51: Reward Update Application in the formal spec). db-sync is probably not removing unregistered credentials.

I was wrong when I said:

moreover, if the (re)registration certificate landed in a transaction in epoch 233, then this would be the only reward update that it would miss out on.

In fact, @SebastienGllmt was exactly right when he said:

You should expect two epochs to be missing:

The epoch where the rewards were sent back to the reserves because they didn't have their stake key registered
The epoch representing the 1 epoch gap between when they deregistered their key and when they re-registered

By not being registered on the 232/233 epoch boundary, the stake credential both:

does not get the rewards from the update being applied on the 232/233 boundary, and
is not included in the stake distribution snapshot taken on the 232/233 boundary (so that it does not get the rewards handed out on the 235/236 boundary).

I can guess how db-sync is reporting rewards being handed out on the 232/233 boundary (which is really just @SebastienGllmt 's guess :) ). The ledger state cannot know until the last moment before the epoch boundary which credentials are still registered. We return rewards for unregistered credentials to the reserves. (See Figure 51: Reward Update Application in the formal spec). db-sync is probably not removing unregistered credentials.

@SebastienGllmt 's picture above looks great, but note that in fact the arrows need to span another epoch to account for the block producing phase. for example, the rewards from the snapshot taken on the 230/231 boundary is not actually handed out until the 233/234 boundary.

@SebastienGllmt 's picture above looks great, but note that in fact the arrows need to span another epoch to account for the block producing phase. for example, the rewards from the snapshot taken on the 230/231 boundary is not actually handed out until the 233/234 boundary.

Ok now we have an explanation of this. db-sync maintains legder-state and pulls out the epoch rewards as a Map StakeAddress Coin which it inserts into the database. However, that map contain StakeAddress entries which are not valid.
The solution is to also pull the set of valid StakeAddress from ledger state and then filter the Map dropping all entries that do not occur in the set of valid StakeAddresses.

Ok now we have an explanation of this. db-sync maintains legder-state and pulls out the epoch rewards as a Map StakeAddress Coin which it inserts into the database. However, that map contain StakeAddress entries which are not valid.
The solution is to also pull the set of valid StakeAddress from ledger state and then filter the Map dropping all entries that do not occur in the set of valid StakeAddresses.

It would be great if this 'phantom' rewards will be put in a new table like 'nondistributed_rewards' or something like this. This will allow us to correctly calculate the pool profitability

It would be great if this 'phantom' rewards will be put in a new table like 'nondistributed_rewards' or something like this. This will allow us to correctly calculate the pool profitability

@dmitrystas :

It would be great if this 'phantom' rewards will be put in a new table like 'nondistributed_rewards' or something like this. This will allow us to correctly calculate the pool profitability.

I can see that these undistributed rewards (that go back to the reserves) could be used to calculate poll profitability but I am pretty sure that is not the best or the easiest way to calculate it.
I have created a ticket specifically for this issue.

@dmitrystas :

It would be great if this 'phantom' rewards will be put in a new table like 'nondistributed_rewards' or something like this. This will allow us to correctly calculate the pool profitability.

I can see that these undistributed rewards (that go back to the reserves) could be used to calculate poll profitability but I am pretty sure that is not the best or the easiest way to calculate it.
I have created a ticket specifically for this issue.

Ok, I have a solution that filters out invalid rewards from the rewards list before being inserted and indeed there is on reward for that address in epoch 231 .
I now need to modify that so that these "invalid" rewards can be added to a separate table.

Ok, I have a solution that filters out invalid rewards from the rewards list before being inserted and indeed there is on reward for that address in epoch 231 .
I now need to modify that so that these "invalid" rewards can be added to a separate table.

Using the version of db-sync in PR #469. the reward for stake address \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde is correctly inserted into the orphaned_rewards table:
cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde';
                           hash_raw                           | epoch_no |  amount
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

and it is also absent from the rewards table:
cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)

Using the version of db-sync in PR #469. the reward for stake address \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde is correctly inserted into the orphaned_rewards table:
cexplorer=# select stake_address.hash_raw, orphaned_reward.epoch_no, orphaned_reward.amount
         from orphaned_reward inner join stake_address on stake_address.id = orphaned_reward.addr_id
         where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde';
                           hash_raw                           | epoch_no |  amount
--------------------------------------------------------------+----------+-----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |      231 | 192969560

and it is also absent from the rewards table:
cexplorer=# select stake_address.hash_raw as "stakeAddress", "totalReward".* from stake_address
    left outer join (SELECT addr_id, amount, epoch_no  FROM reward) as "totalReward"
     on stake_address.id = "totalReward".addr_id
     where stake_address.hash_raw = '\xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde' ;
                         stakeAddress                         | addr_id |  amount   | epoch_no
--------------------------------------------------------------+---------+-----------+----------
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162720747 |      211
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 162485461 |      212
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167344099 |      213
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 167043060 |      214
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 200722225 |      215
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 191413549 |      216
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 143111843 |      217
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147836812 |      218
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 154740829 |      219
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145433327 |      220
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165631299 |      221
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151825651 |      222
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 169141624 |      223
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165184716 |      224
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 148899668 |      225
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 157838234 |      226
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 223252352 |      227
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 147889017 |      228
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 151858721 |      229
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 165782849 |      230
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 135711434 |      232
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 | 145964545 |      233
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    100702 |      235
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |    102078 |      236
 \xe1e27b674f2c9e5c88689526e987ecc7911c034a0f553289e6d3a38fde |   38266 |        65 |      238
(25 rows)


github - Column Graph format

Hi Community / Anoop
I am trying to repurpose formatting jason posted here - https://github.com/pnp/list-formatting/tree/master/view-samples/column-graph
I am working on creating dynamic column graph format out of my Microsoft list, wanting to see status of open position (list has a column named status that has different status including fulfilled, new, open, in-progress etc.) for different role types (Pm, developer etc.) by count or assignee.
Reaching out to get your help in modifying existing jason to get the expected bar graph (than #views/blog).
Can you please suggest changes or share updated jason to achieve bar graph to show count of status type by role type OR count of status by value.
Attaching the list for reference.

Any issue related on the community provided samples should be created on the specific repositories - in the case of this sample, the location would be https://github.com/pnp/List-Formatting/issues
This issue list is for the issues in the product and in the documentation


(PUP-5834) Add support for resource ext_parameters to catalog

This PR adds a new ext_parameters entry to the JSON object that represents a Resource. The ext_parameters, like parameters is an object keyed by parameter names. The values are however not plain JSON types but instead an array representing an extended type created by the Puppet Serialization API.
Special hooks into the serializer enables several values to be generated, one at a time, while using the same tabulation context for all resources in the catalog.

CLA signed by all contributors.

Think this needs unit tests that take a catalog containing ext_parameters written to disk and then applied to show that rich data types survive catalog serialization and can be used agent side. This in turn may require a new resource type as none of the existing types make use of rich data types.

I agree that a test must be written that involves a master and an agent where ext_parameters are applied. I think though, that we really must have an acceptance test that does that. Just writing unit test that writes the json to disk and then read it again will only test disk I/O.  If you agree that an acceptance test is needed, then duplicating more or less the same steps in a unit test is just pointless.

The unit test is far from meaningless and much more than just deserialization as it tests an apply cycle without first having done a compilation - i.e. it tests that a "puppet apply of catalog with rich data" works (and does not regress). The two codepaths (apply and apply catalog from disk) are very different as when you are using apply from source the compilation results will be used without serialization thus using resources that hold the instances that the evaluator created and assigned. The unit test should jog that it is possible to find types on the agent side and instantiate them. Maybe it is not possible to do this without too much mocking - but it would be best if there was a unit test for this.
For the actual interaction between an agent and a master, other features (also) come into play. Not sure if we are missing features here - maybe the request to the master needs to contain if the agent accepts rich data or not (rather than it being a configuration option master side per environment). We will leave it as implemented for starters and then discuss this more widely. As this is experimental at this point, it does not matter that much that the configuration has to be changed on both master and agent side (at least I assumed the agent also needed to turn on rich data since the setting is in the MAIN section).

Ping @adrienthebo - this is the work that enables things like Binary and Encrypted values to be transported to an agent in the catalog. (Experimental behind a feature flag to begin with).

The only advantage of having coverage in unit tests of code-paths that will be covered in acceptance tests, is that they trigger earlier in the process. Do we really need that for this particular case? I find that questionable. Add the concern for "too much mocking" (which I agree with), and the motivation for spending time on writing such a unit test becomes rather hard to find. Do you really want to make this a priority @hlindberg?

I do think it is of value to have non acceptance tests that cover the functionality. As the code stands now, only "half" of the solution is covered together with the lower level features used by the agent side. I think it is of value to show that - if a suitable plugin sync has been performed to an agent, then, the configuration of "puppet apply" will work (essentially that the configuration of environment/loaders/modules agent side indeed works). An acceptance test is needed to test that a real plugin sync via http access works and that it brings over the artifacts in such a way that the agent can use them - but an acceptance test is not required to test the rest. The integration test I am thinking of would contain a custom type, and a custom provider and should assert that this works if the module containing that is placed where pluginsync places it. It could do this by writing a canned catalog to ensure that a compilation is not performed where resources created by the compilation ends up being reused. My suspicion is that it simply does not work agent side as the code stands (for example an Object type bound to an implementation). I believe a canned catalog apply is relatively easy to achieve (there are already similar tests in spec/application/apply_spec.rb).
I tried finding unit/integration tests for plugin sync (what exactly is synced and how) as those would also benefit from not requiring an acceptance test for every detail. Have not found them yet at least.

@thallgren this is failing the commits test because of a FACTER commit that I guess must be on master (in error). Not sure how to proceed.

No, not FACTER, it fails on some commit comment constraint. Looks like a bug in the constraint to me, because I can't see anything wrong with the commit comment.


Backport 2.16: Guard from undefined behaviour in case of an INT_MAX max_pathlen

When parsing a certificate with the basic constraints extension, the max_pathlen that was read from it was incremented regardless of its value. However, if the max_pathlen is equal to INT_MAX (which is highly unlikely), an undefined behaviour would occur. This commit adds a check to ensure that such value is not accepted as valid. Relevant tests for INT_MAX and INT_MAX-1 are also introduced.
Certificates added in this commit were generated using the test_suite_x509write, function test_x509_crt_check. Input data taken from the "Certificate write check Server1 SHA1" test case, so the generated files are like the "server1.crt", but with the "is_ca" field set to 1 and max_pathlen as described by the file name.
This PR addresses IOTSSL-2774.

Backport of https://github.com/ARMmbed/mbedtls/pull/3192


docker-compose error: ERROR: for nginx-proxy  Container command

nginx-proxy:
  image: jwilder/nginx-proxy
  ports:
    - "80:80"
    - "443:443"
  restart: always
  environment:
    - DEFAULT_HOST=njord.weare.de.com
  volumes:
    - /srv/certs:/etc/nginx/certs:ro
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - /etc/nginx/vhost.d
    - /usr/share/nginx/html

this errors out with: ERROR: for nginx-proxy  Container command '/app/docker-entrypoint.sh' not found or does not exist.
running it as docker command works perfectly

Can you try with verbose? docker-compose --verbose up etc? look for /app volumes etc. Also might be useful to use run a have a look around docker-compose run --rm nginx-proxy bash.
Did this happen on first run or did you do up with different volumes etc?

actually, I believe I mis interpreted my issue. I've problem when running my full script. When i ran it separately it works.
so:
sudo docker-compose up -d nginx-proxy works fine
sudo docker-compose up -d gives errors
nginx-proxy:
  image: jwilder/nginx-proxy
  ports:
    - "80:80"
    - "443:443"
  restart: always
  environment:
    - DEFAULT_HOST=njord.weare.de.com
  volumes:
    - /srv/certs:/etc/nginx/certs:ro
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - /etc/nginx/vhost.d
    - /usr/share/nginx/html

nginx-certs:
  image: jrcs/letsencrypt-nginx-proxy-companion
  volumes:
    - /srv/certs:/etc/nginx/certs:rw
    - /var/run/docker.sock:/var/run/docker.sock:ro
  volumes_from:
    - nginx-proxy

gitlab:
  image: gitlab/gitlab-ce:8.6.5-ce.0
  hostname: gitlab.weare.de.com
  ports:
    - "80"
    - "443"
    - "<IP_ADDRESS>:22:22"
  restart: always
  environment:
    - VIRTUAL_HOST=gitlab.weare.de.com
  volumes:
    - /srv/gitlab/config:/etc/gitlab
    - /srv/gitlab/logs:/var/log/gitlab
    - /srv/gitlab/data:/var/opt/gitlab

Weird. Verbose log would probably help to see whats going on

hah, I cannot recreate it. and verbose doesn't log anything suspicious, even the whole thing runs fine now :S I'm new to docker, is this something to be expected? you also mentioned it could be first run issue?

Ah ok. Should not be expected i think... but i know that volumes sometimes can be a bit confusing, also docker-compose adds some smartness for data volumes where it moves volumes between containers for the same service. With first run i meant if it worked the first time but not later on.

well, I rebooted server. it didn't work well before reboot. in any case, thanks for looking in :) I'm closing this down.

No problem 👍


Base url not founf

https://github.com/Constellation-Labs/documentation-hub/blob/main/hypergraph/API/01-global-apis.md
Base urls:
TestNet: https://l0-lb-testnet.constellationnetwork.io/
IntegratioNet: https://l0-lb-integrationnet.constellationnetwork.io/
MainNet: https://l0-lb-mainnet.constellationnetwork.io/

after clicking them its telling not found

Hey @prateushsharma these URLs without the endpoints will return 404 not found. Take a look at the APISpecs where you'll see the endpoint, such as https://l0-lb-testnet.constellationnetwork.io/cluster/info


Xcode 12 build failure

I can see this error in new XCode 12
The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

Hello @golangnext, fixed the issue, please check out version 0.0.6, have an even greater day!


Hide voice and video icons

On Tchap web v2
Hide voice and video icons, as the option is disabled

Done.


Annotations per utterance

Hi,
In the 'omg_TrainVideos.csv', corresponding to each utterance clip, there is only one pair of valence-arousal values written. But inside the 'DetailedAnnotation' folder, if we go to that utterance, we can find multiple text files containing various valence-arousal values. So, how is each utterance split? For example, in OMGEmotionChallenge-master/DetailedAnnotation/train/0e02ee3c5_2/utterance_11.mp4/utterance_11.mp4', I can see 0-4 text files.
Kindly help me understand this.
Thanks,
Vandana

The multiple text files correspond to annotations from different annotators and the csv file contains the gold standard annotation. Thanks for the info @pablovin


fix: gate transformers on valid non-nil destinations

This builds on #203 which attempted to provide a more flexible gating to
running transformers. However upon testing #203 in my own environment, I
ran into the first panic listed below.
There are a variety of errors that can happen when trying to run
reflection on zero values:
2 just from my testing of this PR
        panic: reflect: call of reflect.Value.Type on zero Value

        panic: reflect: call of reflect.Value.FieldByName on zero Value

The panic specifically calls out zero values, but it's actual a more
specific set of values which is covered by reflect.IsValid.
I attempted to replace the check with reflect.IsZero, which ends up
being too restrictive and breaks existing tests. I also attempted to
solely use reflect.IsZero which is not restrictive enough and cause
the later panic above in the tests. Thus I arrived on the combination in
this PR which seems to strike the "right" balance.

Added a test for the specific panic I alluded to in #203, I had significant trouble reproducing the case my integration tests were hitting so I ultimately settled for adding the test in the way I did as I didn't want it to be left entirely uncovered.

@imdario Just poking you again as a reminder to peek at this. Hope ya had a lovely weekend

@zaquestion It wasn't as pleasant as I expected. Sorry for the delay. It looks good, all tests are green and the code feels quite right.


When RMapCache is used, a large number of MapCacheEvictionTask objects are created

After RMapCache is used, a large number of MapCacheEvictionTask objects are created when the expiration date is expired, and the memory is gradually increased. What is the problem?
The version is:
<dependency>             <groupId>org.redisson</groupId>             <artifactId>redisson-spring-boot-starter</artifactId>             <version>3.17.7</version>  </dependency>
config:
` String cluster = "<IP_ADDRESS>:7019,<IP_ADDRESS>:37019,<IP_ADDRESS>:7019,<IP_ADDRESS>:37019,<IP_ADDRESS>:7019,<IP_ADDRESS>:37019";
String[] nodes = cluster.split(",");
for (int i = 0; i < nodes.length; i++) {
nodes[i] = "redis://" + nodes[i];
}
    Config config = new Config();
    config.useClusterServers()
            .setScanInterval(10000)
            .setPassword(properties.getPassword())
            .addNodeAddress(nodes);
    RedissonClient redisson = Redisson.create(config);`

my code:
`@Autowired
private RedissonClient redissonClient;
@Override
public boolean isExist(String key) {
RMapCache map = redissonClient.getMapCache(key);
return map.get(key) != null ? true : false;
}
@Override
public void putEntry(String key, String value) {
    RMapCache map = redissonClient.getMapCache(key);
    map.put(key, value, 300, TimeUnit.SECONDS);
}`

hprof analysis:

You need to call RMapCache.destroy() method once you finished it's usage or use a single instance.

你好，来信收到！

You need to call RMapCache.destroy() method once you finished it's usage or use a single instance.

But I don't know when it finished 。Maybe I should use redis to store it.

RMapCache map = redissonClient.getMapCache(key);
        map.put(key, value, expireTime, TimeUnit.SECONDS);
        map.destroy();

Will the data be stored in redis if used this way? Then the expiration redis will be automatically eliminated
@mrniko


display different images depending on theme

Hi!
Thank you for amazing framework! I would like to display different images in mdx file depending on current theme. I have no idea how to do this? Any tips?
Thank you!

closing since not related to nextra, you can achive this in a different ways, for example with tailwindcss
import lightImg from '...'
import darkImg from '...'
import Image from 'next/image'

<Image src={lightImg} className="dark:hidden" />
<Image src={darkImg} className="hidden dark:block" />

or with CSS https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

Thank you @B2o5T!


Ensure ValueNotifier never notifies twice

Hi,
This tiny fix is about do not add _indicatorsListener() twice even if didUpdateWidget() is called.
Closes #16
Regards:
Janos Roden

Or we can remove didUpdateWidget()

@leocavalcante thanks for merging this. Can I kindly ask you to publish this as v.2.0.3? :)

Sorry 😄
https://pub.dev/packages/page_view_indicator/versions/2.0.3

Thanks :smile::muscle:


Failed to parse JSON

Failed to parse JSON from Any Xtube Profile pages.
"https://www.xtube.com/profile/12345" is fake.

[x] I've verified and I assure that I'm running youtube-dl 2019.03.09
[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[X] Searched the bugtracker for similar issues including closed ones
[X] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser
[X] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', 'https://www.xtube.com/profile/12345']
[debug] Encodings: locale cp932, fs mbcs, out cp932, pref cp932
[debug] youtube-dl version 2019.03.09
[debug] Python version 3.4.4 (CPython) - Windows-7-6.1.7601-SP1
[debug] exe versions: ffmpeg N-93151-gff03418348
[debug] Proxy map: {}
[XTubeUser] 12345: Downloading videos JSON page 1
ERROR: 12345: Failed to parse JSON (caused by ValueError('Expecting value: line 1 column 1 (char 0)',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 891, in parse_json
File "C:\Python\Python34\lib\json_init.py", line 318, in loads
File "C:\Python\Python34\lib\json\decoder.py", line 343, in decode
File "C:\Python\Python34\lib\json\decoder.py", line 361, in raw_decode
ValueError: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 891, in parse_json
File "C:\Python\Python34\lib\json_init.py", line 318, in loads
File "C:\Python\Python34\lib\json\decoder.py", line 343, in decode
File "C:\Python\Python34\lib\json\decoder.py", line 361, in raw_decode
ValueError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\YoutubeDL.py", line 794, in extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 522, in extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\xtube.py", line 164, in _real_extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 884, in _download_json
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 868, in _download_json_handle
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpy110f8qy\build\youtube_dl\extractor\common.py", line 895, in _parse_json
youtube_dl.utils.ExtractorError: 12345: Failed to parse JSON (caused by ValueError('Expecting value: line 1 column 1 (char 0)',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type youtube-dl -U to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
...
<end of log>

If the purpose of this issue is a site support request please provide all kinds of example URLs support for which should be included (replace following example URLs by yours):

Single video:
Single video:
Playlist:

Note that youtube-dl does not support sites dedicated to copyright infringement. In order for site support request to be accepted all provided example URLs should not violate any copyrights.

Description of your issue, suggested solution and other information
Explanation of your issue in arbitrary form goes here. Please make sure the description is worded well enough to be understood. Provide as much context and examples as possible.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
[XTubeUser] 12345: Downloading videos JSON page 1
ERROR: 12345: Failed to parse JSON (caused by ValueError('Expecting value: line 1 column 1 (char 0)',));

> py -2.7 .\youtube_dl\__main__.py http://www.xtube.com/profile/greenshowers-4056496 -F
[XTubeUser] greenshowers-4056496: Downloading videos JSON page 1
[XTubeUser] greenshowers-4056496: Downloading videos JSON page 2
[XTubeUser] greenshowers-4056496: Downloading videos JSON page 3
[XTubeUser] greenshowers-4056496: Downloading videos JSON page 4
[download] Downloading playlist: greenshowers-4056496
[XTubeUser] playlist greenshowers-4056496: Collected 154 video ids (downloading 154 of them)
[download] Downloading video 1 of 154
[XTube] IVcRV-G675-: Downloading webpage

Thankyou response.
I try change "ip".
sucess!


Error on try catch block

I'm trying to deploy a function to firebase, and looks like one of the packages I use, uses p-limit, and when trying to deploy the function, in the installation modules package the console gives me the following error:
Detailed stack trace: /srv/node_modules/p-limit/index.js:30
} catch {}
inspecting the p-limit code in my node_modules I see this in line 28
try { 	await result;   } catch {}
there's an error in the catch expression, is missing the parenthesis after catch, catch(error) {}
Firebase functions uses node version 8
https://github.com/sindresorhus/p-limit/blob/master/index.js#L30

This package requires Node.js 10: https://github.com/sindresorhus/p-limit/blob/824edb836eedc9929ea383457cd82d8367f7322e/package.json#L14
You could downgrade to an older version.

I have tried this on node 12

I have tried this on node 12. Let me check again, just to be sure

Ok it works in node 10 and 12. Sorry for that :smile:


Naming REPL blocks

I just realize that the brand new help, pkg and shell modes in REPL blocks do not accept names (they don't show up as evaluting cell myname during website build).
As a side note, is it possible to execute these blocks in the same context as plain code blocks? Eg defining a function in a code block and playing with it in a REPL block?

julia> s = """
       ```!foo
       x = 5
       ```

       ```>bar
       y = x + 2
       ```
       """
"```!foo\nx = 5\n```\n\n```>bar\ny = x + 2\n```\n"

julia> println(html(s))
[ Info:   ⏯  evaluating cell foo...
[ Info:   ⏯  evaluating cell bar_1...

x = 5

julia> y = x + 2
7

isn't that what you want?

Right, maybe I screwed up or missed them in the crowd. Closing for now


Fix examples

Coverage remained the same at 64.622% when pulling 88f26420283d2ea107570ca8d741cd6cedf514c8 on pyros2097:patch-1 into f4671c3635aba87ef606b7cf4d736b29c401ee63 on shogo82148:master.

Thank you!


Conduct brain storming regarding the design of a new module for causality measures

I did a quick search and found the statsmodels module which looks in general very interesting.


[Feature Request]: Add credential scanning to the CICD process

Description
It would have been nice to add some mechanism for secret scanning in the CICD setup. Both on the github and ado side;

integrated a sample over here:
https://github.com/fblix/ResourceModules/actions/runs/3601328513
Next step would be to check the baseline file if all of the findings really are false-positives.
The baseline file location under /utilities/pipelines/credscan is still up for discussion.
This is the included logic (will also be present on the associated branch):
name: '.Platform: RunCredScan'

on:
  workflow_dispatch:
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install detect-secrets using pip
        run: pip install detect-secrets

      - name: Run detect-secrets tool
        run: |
          detect-secrets --version
          cp utilities/pipelines/credScan/.secrets.baseline .secrets.current
          detect-secrets scan --baseline .secrets.current $(find . -type f ! -name '.secrets.*' ! -path '*/.git*' ! -name 'readme.md')
          ls

      - name: Upload Secret Baseline as Artifact
        uses: actions/upload-artifact@v2
        with:
          name: secret-baseline
          path: utilities/pipelines/credScan/.secrets.baseline

      - name: Upload Findings from current run as Artifact
        uses: actions/upload-artifact@v2
        with:
          name: secret-current-run
          path: .secrets.current

      - name: Compare Results
        run: |
              list_secrets() { jq -r '.results | keys[] as $key | "\($key),\(.[$key] | .[] | .line_number)"' "$1" | sort; }

              if ! diff <(list_secrets utilities/pipelines/credScan/.secrets.baseline) <(list_secrets .secrets.current) >&2; then
                echo "Detected new secrets in the repo" >&2
                exit 1
              fi

Thanks for the quick response. I assume we would need something similar on the ADO side, but potentially with a different set of tools/tasks.

We have a similar logic for ADO as well, got that one working as well. So it would be the same core tool that we utilize.


The code is incomplete

Hi @xanderchf,
Thanks for your great work. It would be a great help if you can you release the full code.

@xanderchf  Thanks for your replay. I already fixed it.

The same problem.
Where is the constants and utils file?
@LongLong-Jing How did you fix it.

@ksnzh
The function is only for adjusting the learning rate. I will push my code into the projects.

Where is the constants and utils file?


Editor - Expand Settings

[x] Add word wrap, other common format settings
[x] Add dropdown to manually select syntax (ace mode)

Added Ace Modes


feat(join): leverage band conditions in hash join

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Leverage band conditions in hash join.
Emit watermarks by band conditions in non-equi conditions in join condition of streaming hash join.
Clean state by band conditions in non-equi conditions in join condition in streaming hash join executor.
Checklist For Contributors

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[x] I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

[ ] I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

[x] My PR DOES NOT contain user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Could we add a watermark in JoinSide and do the state cleaning logic inside the JoinSide?
considering if we have a side's entry it is inserted but never matched, so we can not clean. we need to filter the useless data with the watermark when it is inserted.

However some watermarks need to be emitted into downstream.
We cannot filter at present or we cannot pass sanity check, but perhaps we can improve our sanity check in the future.


Streaming Issue, Not sure what I'm doing wrong and would like help.

Description

My PC will not stream video nor audio to the headset, all thats seen in the headset is black even when in the Steam Home.

I tested with one of the nightly releases. didn't work.
General Troubleshooting

[O] I carefully followed the instructions in the README and successfully completed the setup wizard
[O] I read the ALVR GitHub Wiki

Environment
Hardware
Note: for Linux, an upload to the hw-probe database is preferred: hw-probe -all -upload
https://linux-hardware.org/?probe=b25beba6f3
CPU:
i5-6500
GPU:
RX 580 8 GB
GPU Driver Version:
can't find where this is, if needed please provide an explanation, I'm dumb lol.
Audio:
Pulseaudio
Installation
ALVR Version:
20.11.1
ALVR Settings File:
SteamVR Version:
Not Beta, I believe it's the stable version.
Install Type:
Portable
OS Name and Version (winver on Windows or grep PRETTY_NAME /etc/os-release on most Linux distributions):
Linux Mint 21.3
Edit: I'm trying to stream to a Quest 2

Did you read through the wiki, especially the linux troubleshooting page? Note that the first entry there will always be needed currently due to SteamVR being annoying


[DISCUSS] add a java profile to be able to skip python/go when not relevant for current work

Often working on a feature or even more on a fix you only care about a language - which is probably most of the time java?
When building the project, the python execution time is very important (like half of it on my machine). However you are sure you didn't affect it since the code is quite parallel and almost unrelated in term of dependency.
This PR adds a java profile which skips python/go sdk when building. It is designed to be activable through a property you can put in your settings.xml if you always only work with java part of beam.

I like this idea.

Seems like a good idea, though please bring it up on the mailing list - I think it's been discussed before and it'd be good if people who participated in that discussion chimed in. As a workaround, I typically use -pl sdks/java/core -am -amd.


ExpansionPanelSummary content props

The ExpansionPlanelSummary content cannot be targeted through props. Leaving the only why to style the content div of a ExpansionPanelSummary is to use a ThemeProvider that targeting all ExpansionPlanelSummary components under the scope
 <div className={classNames(classes.content, { [classes.expanded]: expanded })}>
     {children}
  </div>

[x] This is a v1.x issue (v0.x is no longer maintained).
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

There should be a property called contentProps that gets extended onto the content div
 <div {...contentProps} className={classNames(classes.content, { [classes.expanded]: expanded }, contentProps.className)}>
     {children}
 </div>

Current Behavior

There is no way to target styling of the content area
Your Environment

Tech
Version

Material-UI
v1.2.1

React
v16.4

browser
Chrome

There is no way to target styling of the content area

@KamalAman You can use the classes property: https://material-ui.com/customization/overrides/#overriding-with-classes.

@oliviertassinari i'm using the classes property and i can only seem to style the content component when it's not expanded. What is the trick for styling the content component when it is expanded?

@dumptruckman It's the very topic of https://twitter.com/olivtassinari/status/1069695333435928576. In your case, what are you doing with the expanded style rule? It has a corresponding class name that should be provided  to the expansion panel.

@dumptruckman Looking at the issue history, you requirement seems common enough to add a customization demo in the documentation. I'm reopening.


Deep nested object type inference

TypeScript Version:  3.6.4

Search Terms: Deep nested object type inference
Code
export interface A {
	b: B[];
}

export interface B {
	c: C[];
}

export interface C {
	d: D[];
}

export interface D {
	e: E[];
}
export interface E {
	id?: string;
}

// Doesn't work as expected
export const a1: A[] = [
	{
		b: [
			{
				c: [
					{
						d: [
							{
								e: [{ f: 'f' }], // Doesn't show error on f: 'f'
							},
						],
					},
				],
			},
		],
	},
];

// Work as expected
export const a2: A = {
	b: [
		{
			c: [
				{
					d: [
						{
							e: [{ f: 'f' }], // Does show error on f: 'f'
						},
					],
				},
			],
		},
	],
};

Expected behavior: Show error for unknown property 'f'
Actual behavior: Doesn't show error for unknown property 'f'
Playground Link:
http://www.typescriptlang.org/play/?ts=3.7-Beta#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgQTgG8AoASACMAuOAIQG0BdAbhIF8STRJZEU0suOsXLYaAYSasOXcNHjJUGHHnEiyAExoARKe07d5fJYLzb1wGgFE9HQ70UCVcK+oQaA-DQDOMKMgBzaQM5XmwIJF84TABGGnwmOABeOHpyUjJKGjTMsgzcsVTyXLzikq0iktz8qrJLVKI4dBoAcnQWuDZGABoykrZe2p6+sgG+4dyxzImxlhCeeHDI+EwAJnjk9WpK0oLsvprMipyqw9z6+kbmuDaOrsGqqZKJyYeyF6nhtlYgA
Related Issues:

This is fixed in the Nightly build

Duplicate of #34619
Did that fix not make it into 3.7?

The fix missed 3.7; it will be in 3.8


print PDF

Firstly, Thanks for the package!
so is there a way to send a PDF directly to the printer as bytes maybe?

Firstly, Thanks for the package!
so is there a way to send a PDF directly to the printer as bytes maybe?

ESC / POS do not have PDF printing command

I think you can convert PDF to bytes and convert that bytes into images, as the package has the property to print images. I think this will be the option may be!


remove invalid special case in regalloc

We had special case in regalloc if we are storing to a tmp reg and the next instr has the same dst, we don't need to insert a store. Unfortunately, this is invalid in case the sym is also a source of the next instr.
Benchmark perf is flat.
OS: 11480955

Did you measure x86 as well?

:shipit:

Yup, measured both x86 and x64.


Update plugin dev setup docs. Also add link to plugin docs in contribution docs

Summary
This PR adds docs for setting up a plugin development environment, and other related information, namely:

Setting up local environment to deploy plugins
make command descriptions
Exposing the MM server with ngrok
Debugging the server-side of the plugin using delve
Adding CSRF token to requests from the webapp using Client4.getOptions
Using the SiteURL for requests coming from the webapp

This PR also creates a link from the contribution docs to these plugin docs. This is to increase visibility to new contributors. I've used two pages there to have it match the visual aspect of the other sections above it in the docs. It also links to this issue that serves as a proxy to the plugin repo HW tickets.

Some plugins do not have everything described in this PR at the moment, but I am working on spreading this functionality to the other plugins in parallel of updating these docs.
The page called Proper Configuration is supposed to convey that it solves "gotcha"s. I'm not sure what to name the page so I've basically made a placeholder for the name.

Thanks, @mickmister!
WRT "proper configurations", is there a list of gotchas that this is answering? One option could be to make it into a troubleshooting guide if there are specific use cases for the suggested solutions.

@justinegeffen Thanks for reviewing :+1:   I've committed some of the changes and replied to your comments

@aaronrothschild Are you fine with merging this PR as it is?

@aaronrothschild @mickmister Heads up that I'm going to merge this PR as it's a huge improvement already.


adds golang example with web.go

Uses the unofficial golang client library (with a few tweaks) and the web.go web framework

closing this to develop an example using https://github.com/recurly/recurly-client-go


Action bridge

This is https://github.com/ros2/ros1_bridge/pull/256 rebased on master.

ref https://github.com/schiller-de/amr_platform_orga/issues/60
ref https://github.com/mojin-robotics/cob4/issues/2000

I updated mojin-robotics/ros1_bridge#master branch to be synced with latest ros2/ros1_bridge#master updates
now this branch has a merge conflict
@LoyVanBeek

Rebasing is not so easy anymore due to reformatting which makes things harder to see. I tried to re-rebase that didn't work out in the end.

@LoyVanBeek
we changed the target branch to mojin-devel
as https://github.com/mojin-robotics/ros1_bridge/pull/3 is merged now, this PR has a merge conflict
could you rebase and resolve the conflict and then test the action support another test - see https://github.com/4am-robotics/orga/issues/2503

I've rebased the action_bridge on top of mojin-devel. I've added a new branch with the rebased version here https://github.com/benmaidel/ros1_bridge/tree/action_bridge.
When tests are successful I'll force-push onto this branch

Tested successfully & OK in https://github.com/4am-robotics/orga/issues/2503#issuecomment-1252013415 so good to force-push and merge IMO


Add support for Kinopoisk.ru

Add search suggestions for popular Russian movie database kinopoisk.ru, similar to IMDB

Although, this is working as intended, Kinopoisk.ru actually returns each suggestion with link to corresponding movie page. So it's more like actual search results, than suggestions. I would love to use this links instead of _search_url URL, but as far as I understand, it's not possible without altering of inner workings of the workflow.
Please, consider to add this functionality in future releases. I think, it can be useful for other web services too.
P.S. Here is JSON response format for the reference.

Thank you for clarification, I'll change implementation of support for kinopoisk.ru to customise search URL for suggestions and open another pull request when it's ready.
Please, consider to leave the possibility customise search URL for suggestions in v2.


Create full frame wcs directly from submap wcs - [merged]

In GitLab by @wtbarnes on Nov 3, 2021, 11:35
Merges spike-submap-wcs -> master
This addresses !125, but creates the full-frame WCS from the submap WCS.
@dstansby1 I tried to push to your branch on your PR but didn't have permission.

mentioned in commit 23d94e8708ba2ca61efd08e52d0ff49ec5495eed

In GitLab by @codecov on Nov 3, 2021, 11:46
Codecov Report

Merging #139 (1719b22) into master (375bccb) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #139      +/-   ##
==========================================
- Coverage   97.50%   97.47%   -0.03%
==========================================
  Files          16       16
  Lines         560      555       -5
==========================================
- Hits          546      541       -5
  Misses         14       14

Impacted Files
Coverage Δ

aiapy/calibrate/spikes.py
98.18% <100.00%> (-0.16%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 375bccb...1719b22. Read the comment docs.

approved this merge request

In GitLab by @wtbarnes on Nov 3, 2021, 12:10
added 2 commits
18c6f2a8 - dont need to update naxisn1719b222 - changelog
Compare with previous version

mentioned in commit<PHONE_NUMBER>18b1a579b95cc8bfb239de02c8b44e

picked the changes into the branch cherry-pick-23d94e87 with commit 935b51ddee1246e0ee489e84a8402ac0afa49739

mentioned in commit 935b51ddee1246e0ee489e84a8402ac0afa49739


fixed  Create proxy and websocket configuration configmap for wrongsecrets-balancer #252

Thank you for submitting a pull request to the WrongSecrets Party!
What kind of changes does this PR include?

[ - ] Fixes or refactors
[x] Platform support
[ ] A new feature
[ ] Additional documentation
[ ] Something else

Checklist:

[ ] All the contributions made are solely the work of me and my co-authors
[ ] I tested the changes in this PR (if applicable)
[ ] I added tests to ensure my change works (if applicable)
[ ] The PR passes pre-commit hooks and automated tests

Hi @MayanK23YadaV !
Thank you for your PR. Is it possible to get in touch via Slack and have a chat about it?

hello sir @commjoen yeah sure i would like to have a chat


Netcdf append

Follow on from https://github.com/scipy/scipy/pull/4960
Fixes two issues which were present when appending to an existing NetCDF file.
First commit fixes the ValueError which appears when in-place resize is used on a numpy array storing a NetCDF record variable. The exception is raised since the array might not be single-segment. The in-place resize is still tried first since it is probably faster than copy resize, whenever it is possible.
Second commit ensures that "data" field is not saved as a user defined attribute, since it is used to access the variable data.
In reply to pv comments in https://github.com/scipy/scipy/pull/4960, .astype is needed at least on line 994 but I would prefer to as well keep it on line 517 just in case.

@@            master   #6021   diff @@
======================================
  Files          238     238
  Stmts        43822   43829     +7
  Branches      8215    8216     +1
  Methods          0       0
======================================
+ Hit          34253   34284    +31
  Partial       2602    2602
+ Missed        6967    6943    -24

Review entire Coverage Diff as of 9cd0278

Powered by Codecov. Updated on successful CI builds.

Thanks for the hints! I updated as suggested.

LGTM, merged. Thanks @radosuav


Default to providing a logger context for events

Default to providing the module class as the log context so we can filter out the day-to-day web surfing log entries.

Updated as noted, thanks!


[stable-3.0] Disabled user can still access their files

Describe the bug
Disabled user can still access their files.

Note this only exists in stable-3.0 branch

Steps to reproduce
Steps to reproduce the behavior:

Create user Alice

curl -u admin:admin -X POST https://localhost:9200/graph/v1.0/users -H "Content-Type: application/json" -d '{"onPremisesSamAccountName":"Alice","passwordProfile":{"password":"123456"},"displayName":"Alice Hansen","mail":"alice@example.org","accountEnabled":true}' -vk

As user Alice upload a file with some content

 curl -u Alice:123456 -X PUT https://localhost:9200/remote.php/webdav/textfile0.txt -d "hello world" -vk

Disable user Alice

curl -u admin:admin -X PATCH https://localhost:9200/graph/v1.0/users/<user-id-of-alice>-H "Content-Type: application/json" -d '{"accountEnabled":false}' -vk

Download the file as user Alice

curl -u Alice:123456 -X GET https://localhost:9200/remote.php/webdav/textfile0.txt -vk

Expected behavior
The request should fail with 401. (this is the behaviour in master)
Actual behavior
the request is successful with 200. The disabled user can create files as well.
Setup
Branch = stable-3.0
commit id = 7c20b189d3307458911b46b1fcee05c67d064366
Additional context
Add any other context about the problem here.

I've created this issue because some tests are failing in the stable branch because of this and the test pass in the master.
If this is something that we don't want to fix for the stable branch then I can close this issue and skip the tests for the stable branch.
cc @micbar

Backporting this would be the fix I think: https://github.com/owncloud/ocis/pull/6516
Note: This issue only affects basic auth, which is disabled by default.

Backporting this would be the fix I think: #6516
Note: This issue only affects basic auth, which is disabled by default.

If this only affects the basic auth should I just skip the tests in the stable branch? or would it be okay to backport the fix to stable as well? I can skip the test if the bug is not that big of an issue because the tests do pass in master.

since we already release ocis-4.0 this issue is no longer relevant so closing this


Feature: add one function 'notes' under Blog methods...

Suppose the following scene: i love nba star cp3,somebody post the infomation or video about Paul, i want to know more about Paul or the people that also likes paul. How can i get these info?
Here is my opinion: I can find that by find who also love the post about Paul, so, the function notes is follow:
/**
   * get one post's notes,includes like or reblog
   * @param  {string}   blogName     bolg name
   * @param  {int}        id                  post id
   * @param  {Function} callback
   */
notes:function(blogName, id, callback){
    this._get(blogPath(blogName,'/notes'),{id:id},callback,true);
  },

and see this
client.notes('lovingbasketball',92886654550,function(err,data){
	var noters = new Array();
	noters['like'] = new Array();
	noters['reblog'] = new Array();
	data.notes.forEach(function(blog){
		noters[blog.type].push(blog.blog_name);
	});
	console.log(noters);
	//return noters;
});

by this way, i get the follow message:
[
    like: ['jraw81','likahbaby','kidhattan','jstarkk','fernvndoec',...],
    reblog: [ 'f32guson','giotabliashvili','jsandjays','asweproceedto',...]
]

Hey there! You can get the notes info by passing notes_info: true already. For example:
tumblr.blogPosts('keithmcknight', { id:<PHONE_NUMBER>17, notes_info: true });

This will load the info for a specific post on my blog including a notes key for each post, kind of like this:
{
  "blog": { /* ... */ },
  "posts": [
    {
      "blog_name": "keithmcknight",
      "id":<PHONE_NUMBER>17,
      "post_url": "http://keith.mcknig.ht/post/145510800617",
      /* ... */
      "notes": [
        {
          "blog_name": "protecthewitch",
          "blog_uuid": "protecthewitch.tumblr.com",
          "blog_url": "http://protecthewitch.tumblr.com/",
          "followed": false,
          "avatar_shape": "square",
          "type": "like",
          "timestamp":<PHONE_NUMBER>
        },
        {
          "blog_name": "pissmother",
          "blog_uuid": "pissmother.tumblr.com",
          "blog_url": "http://pissmother.tumblr.com/",
          "followed": false,
          "avatar_shape": "square",
          "type": "reblog",
          "timestamp":<PHONE_NUMBER>,
          "post_id": "145600972412",
          "reblog_parent_blog_name": "serenepristine"
        },
        /* ... */
      ]
    }
  ],
  "total_posts": 1
}

ok, it looks like you guys release v1.0.0 and change some API, but i couldn't install the lastest version by command npm update tumblr.js

@kmck thanks, i got the notes info by notes_info: true


Remove StrictAware interface as deprecated

The StrictAare interface is deprecated and will be removed from cucumber. This is used in adapter class and needs to be removed.

Added in 2.0.0.


test_run_log_current_job_when_stopping is flaky

I've seen this test fail, in an arbitrary manner.
========================================================================================== FAILURES ===========================================================================================
___________________________________________________________________________ test_run_log_current_job_when_stopping ____________________________________________________________________________

app = <procrastinate.app.App object at 0x7f2240c14d30>, running_worker = <procrastinate.worker.Worker object at 0x7f2240a6be50>
caplog = <_pytest.logging.LogCaptureFixture object at 0x7f2240a6bca0>

    async def test_run_log_current_job_when_stopping(app, running_worker, caplog):
        caplog.set_level("DEBUG")

        @app.task(queue="some_queue")
        async def t():
            running_worker.stop()

        await t.configure(lock="sher").defer_async()

        try:
            await asyncio.wait_for(running_worker.task, timeout=0.5)
        except asyncio.TimeoutError:
            pytest.fail("Failed to launch task within .5s")

        # We want to make sure that the log that names the current running task fired.
>       assert {
            "Stop requested",
            "Waiting for job to finish: worker 0: tests.integration.test_worker.t[1]() "
            "(started 0.000 s ago)",
        } <= set(r.message for r in caplog.records)
E       AssertionError: assert {'Stop requested', 'Waiting for job to finish: worker 0: tests.integration.test_worker.t[1]() (started 0.000 s ago)'} <= {'About to defer job tests.integration.
test_worker.t[None]()', 'Acknowledged job completion tests.integration.test_wor...01 s', 'Loaded job info, about to start job tests.integration.test_worker.t[1]()', 'Registering queue some_qu
eue', ...}
E        +  where {'About to defer job tests.integration.test_worker.t[None]()', 'Acknowledged job completion tests.integration.test_wor...01 s', 'Loaded job info, about to start job tests.in
tegration.test_worker.t[1]()', 'Registering queue some_queue', ...} = set(<generator object test_run_log_current_job_when_stopping.<locals>.<genexpr> at 0x7f2240bb7350>)

tests/integration/test_worker.py:71: AssertionError
-------------------------------------------------------------------------------------- Captured log call --------------------------------------------------------------------------------------

Aaaaah a flaky test. Who doesn't love a flaky test :)

It failed here for example: https://github.com/peopledoc/procrastinate/runs/1124818230


Update itadmin-readiness.md

New Teams Phone shared calling playbook.

#sign-off

@jhwang-ms Please make your changes in the private repo, not the public. Contact me if you need help.