Skip to content

ownedvehicles graphql endpoint and custom address type - #1

Merged
elffjs merged 4 commits into
mainfrom
PRO-1631-owned-vehicles
Jul 10, 2023
Merged

elffjs merged 4 commits into
mainfrom
PRO-1631-owned-vehicles

Conversation

@0xdev22

@0xdev22 0xdev22 commented Jun 28, 2023

Copy link
Copy Markdown
Contributor

No description provided.

@linear

linear Bot commented Jun 28, 2023

Copy link
Copy Markdown
PRO-1631 Owned vehicles API

Let's look at a vehicle mint:

https://polygonscan.com/tx/0xaabf1c76f1ac08ff54f51b4ef1129636f87e59b677747f073468f3b774fa43a3#eventlog

and try to display that information in a GraphQL API. The table:

  • id int primary key
  • owner bytea
  • make varchar
  • model varchar
  • year int
  • mint_time int

I want to serve this from a GraphQL API like

query {
  ownedVehicles(address: String!) {
    id
    owner
    make
    model
    year
    mintTime
  }
}

Comment thread graph/schema.graphqls Outdated
Comment thread graph/schema.graphqls Outdated
Comment thread internal/controllers/owned_vehicles.go Outdated
Comment thread internal/controllers/owned_vehicles.go Outdated
Comment thread graph/types/blockchain.go Outdated
@0xdev22
0xdev22 requested a review from elffjs June 28, 2023 22:20
@elffjs
elffjs requested a review from Allyson-English June 29, 2023 13:32
Comment thread internal/controllers/owned_vehicles.go Outdated

@elffjs elffjs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very minor things.

Comment thread graph/types/blockchain.go

func (v *VehiclesCtrl) GetOwnedVehicles(addr common.Address) ([]*gmodel.Vehicle, error) {
mv, err := models.MintedVehicles(
models.MintedVehicleWhere.OwnerAddress.EQ(null.BytesFrom(addr.Bytes())),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd have to see the table, but: it would be nice if the owner always had to be present, and then we wouldn't need to bother with null. It's difficult to have vehicles without owners.

Comment thread internal/controllers/owned_vehicles.go Outdated
Comment thread migrations/20230628170128_minted_vehicles.sql Outdated
Comment thread migrations/20230628170128_minted_vehicles.sql Outdated
Comment thread migrations/20230628170128_minted_vehicles.sql Outdated
Comment thread migrations/20230628170128_minted_vehicles.sql Outdated
Comment thread graph/schema.resolvers.go Outdated
Comment thread internal/controllers/owned_vehicles.go
Comment thread migrations/20230628170128_minted_vehicles.sql
Comment thread migrations/20230628170128_minted_vehicles.sql Outdated
Comment thread graph/resolver.go Outdated
@0xdev22
0xdev22 requested review from Allyson-English and elffjs July 7, 2023 13:57
@elffjs

elffjs commented Jul 7, 2023

Copy link
Copy Markdown
Member

I see a request for a review, but no recent commits.

@0xdev22

0xdev22 commented Jul 7, 2023

Copy link
Copy Markdown
Contributor Author

I see a request for a review, but no recent commits.

Apologies, fixed

@elffjs

elffjs commented Jul 10, 2023

Copy link
Copy Markdown
Member

What do you think of this?

https://github.com/elffjs/saveboiler/blob/master/init.sql

@elffjs

elffjs commented Jul 10, 2023

Copy link
Copy Markdown
Member

I'm just going to merge this and we'll explore it later.

@elffjs
elffjs merged commit 14d6156 into main Jul 10, 2023
@elffjs
elffjs deleted the PRO-1631-owned-vehicles branch July 10, 2023 13:48
@elffjs elffjs mentioned this pull request Jul 20, 2023
zer0stars added a commit that referenced this pull request Sep 15, 2026
The only source was <base>/manifest.json, a route definitions-worker #1 deletes
without a replacement. Its cutover deploys the worker before identity, and
worker deploys are manual, so the ordering is an operator's to get right: once
the new worker is out, warm pods take the stale-serve path every minute and
freeze on a snapshot that no template edit can reach, and the first pod
restarted afterwards fails every device-definition query. Nothing here guarded
against that or migrated away from it.

Ask <base>/idx/current.json first, conditionally.

  200: the deployment publishes template builds. A build id equal to the one
  held means nothing to do -- shards are immutable -- so an unchanged catalog
  costs one small conditional GET a minute instead of a 7.7 MB download. A new
  build is fetched shard by shard, eight at a time, and each Template is
  flattened the way device-definitions-api flattens it (template-level
  attributes only, sorted by name, strconv-rendered, manufacturer from the
  template, no ksuid), so both services describe a template identically. A
  build is vetted whole: a half-empty shard is a catalog that lost definitions,
  not a shard to serve around. Shard keys are matched against
  idx/<build>/shard-<n>.json before they are fetched, because the index is data
  from the network and must not name a URL of the producer's choosing.

  304: unchanged.

  404: no index deployed, so the flat manifest is read exactly as before.

  Anything else: a refresh failure. A 5xx must never be read as "this
  deployment has no index" and flip a pod to the other source.

A listing in template mode only changes when a build is published, so a
definition created since then is missing from the snapshot. A by-id miss falls
back to <base>/t/<id>.json, which the worker writes when the definition is
created: found is cached (1024 entries, cleared when a build is adopted),
missing is remembered for five minutes (4096 entries), one fetch per id serves
every concurrent caller, and the fetch outlives the caller that started it.
Any other status is a wrapped error. DefinitionsByManufacturer stays
snapshot-only and says so: a listing is a page of results, and fetching it from
the origin would put the catalog back in the request path.

ToAPI now leaves legacyId null when the ksuid is empty. Templates have none,
the schema field is nullable, and &"" answers with a legacy id that resolves to
nothing.

The devicedefinition fixture called require.Equal inside its httptest handler,
which runs on a server goroutine: a path it did not expect would call
runtime.Goexit there, kill the connection without writing a response, and
surface on the test goroutine as an unexplained EOF. It now routes by path
(404 for the index so these tests exercise the legacy manifest), records
anything unexpected, and asserts on that from the test goroutine.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants