Mechanism to await a mutation and be sure it was indexed
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- typescript
- Domaine
- api, blockchain, tooling
Piste de recherche
Commencez par localiser l’outillage grc-20-ts et ses points d’entrée pour publish, sync et l’indexer-API. Comparez les approches polling, publish-through-API et block-hash, puis définissez la condition d’achèvement du mécanisme de sorte qu’il ne retourne qu’une fois la mutation trouvable dans l’index.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
You can get the transaction hash and block number back from the chain at publish-time, but there’s no guarantee that the transaction has actually been indexed yet. We run into this problem in the web app, too. We solve it by just keeping published data in the local store even after it’s published until the user leaves the page. (edited)
There’s a few solution spaces
- Have a mechanism to poll the API looking for your edit id and return when it finds it (this can just be part of syncing in the future)
- Publish edits through an API which returns when it finds your edit in the indexer API
- I think we should incorporate block hash into the API. So you can say “query as of this block hash” or where block > x, or something like that and have a metadata field so you can get back from the server what block it was executed against. I think that should get us through the story here
Probably should be tooling that exists in grc-20-ts?
- Langage dominant
- TypeScript
- Étoiles
- 22
- Forks
- 12
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de graphprotocol/hypergraph
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
graphprotocol/hypergraph#517 ·
-
Section of docs is confusing Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 68/100
graphprotocol/hypergraph#323 · 3 commentaires ·
-
Improve Space Inbox Ouverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
graphprotocol/hypergraph#542 ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
graphprotocol/hypergraph#529 ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
graphprotocol/hypergraph#528 ·
Toutes les issues de graphprotocol/hypergraph
Issues similaires
-
comp/dashboard P3 type/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
NousResearch/hermes-agent#117722 ·
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P3
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 76/100
-
code-quality refactoring
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
github/gh-aw-firewall#8816 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
langchain-ai/deepagents#6450 ·