Closed ross-spencer closed 11 months ago
Hey @ross-spencer I think what you're seeing here is https://github.com/mlabs-haskell/cardano-open-oracle-protocol/issues/53. It's just how the tutorial wallet environment is setup. Feel free to document and further clarify this situation
Hi @bladyjoker can you clarify the mechanics here some more? It's not clear to me how the wallet config here impacts the garbage collection? For example, I am not able to garbage collect POS_INF
statements because this is prevented somewhere in the stack. But then I'm not sure where that's enforced.
Further clarity on my side - parsing coop-state.json
I retrieve all fact statements and timestamps:
3-08-14 12:15:00 INFO :: py_publish.py:135:_process_state_json() :: fact statement ids on-chain: ['04CA000ACC65CA96', '04CA007078C406D0', '04CA00AD7FACF73C']
local datum ids on chain:
{
"ids": [
[
"04CA000ACC65CA96",
"PosInf",
null
],
[
"04CA007078C406D0",
"NegInf",
null
],
[
"04CA00AD7FACF73C",
"Finite",
1692616138
]
],
"total": 3
}
The publisher GRPC service happily accepts all of these (including the one set to never expire):
2023-08-14 12:15:26 INFO :: py_publish.py:135:_process_state_json() :: fact statement ids on-chain: ['04CA000ACC65CA96', '04CA007078C406D0', '04CA00AD7FACF73C']
2023-08-14 12:15:26 INFO :: py_publish.py:327:batch_gc() :: Collecting IDs: [b'04CA000ACC65CA96', b'04CA007078C406D0', b'04CA00AD7FACF73C']
2023-08-14 12:15:26 INFO :: py_publish.py:362:gc_txs() :: certificate file location: /home/orcfax/git/mlabs/coop.0/.coop-publisher-cli/certificate.pem
2023-08-14 12:15:26 INFO :: py_publish.py:103:tls_credentials() :: certificate file location: /home/orcfax/git/mlabs/coop.0/.coop-publisher-cli/certificate.pem
2023-08-14 12:15:26 INFO :: py_publish.py:115:submitter() :: submitting Tx as: bedfff1b6762f7a95437ab8ca30b3244dfe44029125d23656062a8b6
And returns the statements that became obsolete, and reminds us that the one set to never expire is still valid:
}
info {
tx_builder_info {
obsolete_fs_ids: "04CA007078C406D0"
obsolete_fs_ids: "04CA00AD7FACF73C"
valid_fs_ids: "04CA000ACC65CA96"
}
}
Further from the publisher grpc:
"Got from user: {fs_ids: \"04CA000ACC65CA96\" fs_ids: \"04CA007078C406D0\" fs_ids: \"04CA00AD7FACF73C\" submitter { base16: \"bedfff1b6762f7a95437ab8ca30b3244dfe440291
25d23656062a8b6\" }}"
"Sending CreateGcFsTxRequest to TxBuilder: {fs_ids: \"04CA000ACC65CA96\" fs_ids: \"04CA007078C406D0\" fs_ids: \"04CA00AD7FACF73C\" submitter { base16: \"bedfff1b6762f7
a95437ab8ca30b3244dfe44029125d23656062a8b6\" }}"
If the wallet configuration was impacting this, I would anticipate the POS_INF
statement to be collected as well because I would have the authority to do so. Instead something prevents that, but doesn't prevent the "Finite"/"Timestamped" fact from being collected. Note this one was scheduled for 21 August.
So, my questions are:
POS_INF
from being collected?CreateGcFsTxRequest
) function will simply go ahead and collect NEG_INF
and finite
anyway?@ross-spencer this is a different issue, check the title :D Sorry about that!
this is a different issue, check the title :D Sorry about that!
Ah, sorry @bladyjoker forgot about this one! Will find time to document.
This has been documented in the PR associated with this issue.
What do you see?
The tutorial describes the renaming of the submitter key. If the key isn't renamed then the following command will finalize and complete the transaction, submitting it to chain, for the authenticator wallet and submitter wallet.
i.e. if the submitter wallet key is prefixed with
signing-key-
then the publisher command can use that key to submit the transaction.From the publisher gRPC service:
Follow through with submit step users may see an error that looks as follows:
The tutorial requires renaming this wallet:
What do you expect?
If we follow the guide correctly we see:
Expected:
And the transaction can be submitted manually.
What's the problem?
It isn't clear in the guide's steps what the implications are for not renaming the wallet. It is also not clear if this is functionality that should be included in the publishing service.
I suspect it is enough to document the behavior around #L303 if other's agree? - I can follow up with a PR. The documentation might also suggest that it's a valid approach to not rename the submitter signing key, and then revisit this point at step 8 submitting a fact statement manually vs. automatically.