GET /api/v1/network/supplymax_automatic_token_associations in the accounts REST API.receiverSigRequired field. The REST API packages were renamed to use the @hashgraph NPM package scope. This shouldn't be a breaking change as we don't currently publish those packages to NPM. A number of APIs were fixed to ensure lists were returned in a deterministic sort order. Also, the OpenAPI specification was fixed up so that it accurately reflects the current API and can be used to generate client code. Finally, the schedules API had some performance improvements.GET /api/v1/tokens/0.0.1500/nftsGET /api/v1/tokens/0.0.1500/nfts/1GET /api/v1/tokens/0.0.1500/nfts/1/transactionsPodDisruptionBudgets, adjust alert rules and other improvements to make it easier to automate the deployment.type field to the token related APIs to indicate fungibility and anft_transfers to /api/v1/transactions/{id}:leaders is used to atomically elect the leader.master branch to main. If you have a clone or fork of the Mirror Node Git repository, you will need to take the below steps to update it to use main:keepFiles (now renamed to writeFiles) properties to write the stream files to disk after download. It is no longer archived into folders by day. Instead, the folder structure will exactly match the structure in the bucket. This opens the possibility for a mirror node to download and mirror the bucket itself using a S3 compatible API like MinIO. Below is a summary of the renamed properties:hedera.mirror.importer.downloader.balance.keepSignatures to hedera.mirror.importer.downloader.balance.writeSignatureshedera.mirror.importer.parser.balance.keepFiles to hedera.mirror.importer.downloader.balance.writeFileshedera.mirror.importer.parser.balance.persistBytes to hedera.mirror.importer.downloader.balance.persistByteshedera.mirror.importer.downloader.event.keepSignatures to hedera.mirror.importer.downloader.event.writeSignatureshedera.mirror.importer.parser.event.keepFiles to hedera.mirror.importer.downloader.event.writeFileshedera.mirror.importer.parser.event.persistBytes to hedera.mirror.importer.downloader.event.persistByteshedera.mirror.importer.downloader.record.keepSignatures to hedera.mirror.importer.downloader.record.writeSignatureshedera.mirror.importer.parser.record.keepFiles to hedera.mirror.importer.downloader.record.writeFileshedera.mirror.importer.parser.record.persistBytes to hedera.mirror.importer.downloader.record.persistByteshedera.mirror.importer.downloader.consensusRatio property that controls the ratio of verified nodes (nodes used to come to consensus on the signature file hash) to the total number of nodes available.hedera-mirror-test image from 1.5G to 0.5G.env, envFrom, volumes, volumeMounts properties to all charts for more flexible configuration. We added a global.image.tag chart property to make it easier to test out custom versions. And we made it easier to use dependencies that can be outside the cluster like Redis and PostgreSQL.Transaction protobuf in the database is an option that's been available for a while but until now has not been available via the API. Persisting the data is off by default as does increase the size of the database quite a bit. The Hedera managed mirror nodes will not have that functionality turned on to reduce storage.entity_id field on our transactions related APIs. This field represents the main entity associated with that transaction type. For example, if it was a HCS transaction it would be the topic ID created, updated, or deleted.GET /api/v1/transactions/0.0.1009-1234567890-999999998StatefulSet to a Deployment since it no longer has the need for a persistent volume. We also switched the Traefik dependency from a Deployment to a DaemonSet. Both of these will require manual intervention to delete the old workload before upgrading. Support for Helm 2 was dropped since it is no longer supported by the community after November 13, 2020. If you're directly reading from our database, a rename of the t_entities table and its columns may impact you as well.ScheduleCreate and ScheduleSign operations. We've added the three new mainnet nodes the monitor's default configuration. A bug with the monitor unable to reach expected TPS with multiple scenarios was fixed.hedera.mirror.importer.importHistoricalAccountInfo) and works in combination with the hedera.mirror.importer.startDatesetting.account.idand credit/debit filtering options supported HBAR transfers only, this release expands both filters to include tokens also.check-state-proof package have also been improved. The API now supports filtering for scheduled transactions via /api/v1/transactions/:transactionId/stateproof?scheduled=true as-well as a more compact response format. For record streams that utilize the newer improved HAPI v5 version the stateproof API response send back metadata hashes instead of the full raw bytes. With this, the response is more light weight.account.id query parameters when filtering, with a configureable setting for the maximum number of repeated query parameters
/api/v1/(accounts|balances|transactions)?account.id=:id&account.id=:id2...GET /api/v1/accounts?account.id=0.0.7&account.id=0.0.9gosec as-well as the implementation of suggestions from a 3rd party code audit./api/v1/schedules and /api/v1/schedules/:id. The former lists all schedules with various filtering options available and the latter returns a specific schedule by its schedule ID.GET /api/v1/schedules?account.id=0.0.1024&schedule.id=gte:4000&order=desc&limit=10null, empty string or a non-empty string to keep, clear or replace the existing memo, respectively.t_application_status table in favor of calculating the last successful file directly from the stream file tables. In addition to fixing the aforementioned issues, the removal of the filesystem has resulted in a 5% latency improvement.index field to record_file table to simulate a blockchain index and updating our Google Marketplace to v0.27. Also, we added support for the v5 stream files to the check-state-proof client app.newTotalSupply field to the transaction record in HAPI 0.10.0. We also documented our design for the upcoming scheduled transactions services that's coming in a future release of HAPI. Our next minor version will have preliminary support for that./api/v1/openapi.ymland serves as a formal specification of our API. Clients can use the specification to shorten the amount of time it takes to integrate with our API by generating code or tests harnesses. It also provides us with a new auto-generated API documentation site viewable at /api/v1/docs.~/.aws/credentials, etc). See our documentation for more information./api/v1/transactions?transactionType=tokentransfers and /api/v1/transactions?transactiontype=tokentransfers are now both acceptable./api/v1/tokens shows available tokens on the network. A token REST API /api/v1/tokens/${tokenId} shows details for a token on the network. A token supply distribution REST API /api/v1/tokens/${tokenId}/balances shows token distribution across accounts. These APIs have already made their way to previewnet so check them out!transactionType query parameter. This feature can be used with the transactions API in the format /api/v1/transactions?transactionType=tokentransfers while the format for the accounts API is /api/v1/accounts/0.0.8?transactionType=TOKENTRANSFERS.PrometheusRule alerts for each component that trigger notifications based upon Prometheus metrics. A custom Grafana dashboard was created that shows currently firing alerts.signedTransactionBytes field. Since the mirror node still needs to support historical transactions we retain support for parsing transactions that contain the old payload format.hedera.mirror.importer.startDate property can be used to exclude data from before this date and "fast-forward" to the point in time of interest. By default, the startDate will be set to the current time so mirror node operators can get up and running quicker with the latest data and reduce cloud storage retrieval costs. Note that this property only applies on the importer's first startup and can't be changed after that. The hedera.mirror.importer.endDate property can be used to exclude data after this date and halt the importer. By default it is set to a date far in the future so it will effectively never stop.startDate property does change how the mirror node operators on initial start from previous releases. By defaulting to now, users standing up a new mirror node will no longer retrieve all historical data and will instead only retrieve the latest data. Current users upgrading to this release will not be affected even if their data ingest is not fully caught up since this property only applies if the database is empty like it is on first start. To revert to the previous behavior, a date in the past can be specified like the Unix epoch 1970-01-01T00:00:00Z.VertxException: Thread blocked issue seen in #945​0.0.101 and 0.0.102in the mirror node database.
The mirror node will now retrieve file address book contents which include node identifiers and their public keys from the database instead of the file system at startup./transactions/${transactionId}/stateproof.
With this release it is possible to request the address book, record file and signature files that contain the contents of a transaction and allow for cryptographic verification of the transaction. Mirror node users can now actively verify submitted transactions for themselves.record_file table contents are also expanded to include the start and end consensus timestamps of their containing transactions. The record_file table also saw a clean up to remove the path to the file.NotifyingTopicListener that uses PostgreSQL's LISTEN/NOTIFY functionality.topicRunningHashV2AddedTimestamp with a default value for mainnet, making it not fail on startup if a value is not provided. Containerized acceptance and performance tests were added, making it easier to test at scale.hedera.mirror.grpc.listener.bufferInitial and hedera.mirror.grpc.listener.bufferSize properties since we removed the shared poller's buffer.t_transactions to transaction, t_cryptotransferlists to crypto_transfer and non_fee_transfers to non_fee_transfer.hedera.mirror.importer.downloader.endpointOverride for testing. We also added hedera.mirror.importer.downloader.gcpProjectId to support specifying requester pays credentials with a personal account. Finally, we improved our Marketplace support getting us one closer to making it available.runningHashVersion to the REST and GRPC APIs. Finally, we added transactionHash to the transaction REST API.hedera.mirror.importer.downloader.record.keepSignatures=true and hedera.mirror.importer.downloader.balance.keepSignatures=true.t_application_status. Since this data is not application state but considered more a user supplied value, we added a new property hedera.mirror.importer.verifyHashAfter=2020-06-05T17:16:00.384877454Z for this purpose.encoding=utf-8and the REST API will make a best effort conversion to string. By default or if you pass a query parameter of encoding=base64, it will return the message as base64 encoded binary.hedera.mirror.api properties to hedera.mirror.rest. We also renamed the properties apiUsername to restUsername and apiPassword to restPassword to reflect that as well. Any properties that were used by the importer module were renamed to be nested under hedera.mirror.importer. We apologize for any inconvenience.hedera.mirror.addressBookPath property in favor of a hedera.mirror.importer.initialAddressBook property. The former was overloaded to be both the initial bootstrap address book and the live address book being updated by file transactions for 0.0.102. The live address book is now hardcoded to ${hedera.mirror.importer.dataPath}/addressbook.bin and cannot be changed./topics/messages/:consensusTimestamp) and singular (/topic/message/:consensusTimestamp) URI path. The singular format is deprecated and will be going away in the near future, so please update to the plural format soon./topic/:id/message API was removed in favor of the plural form /topics/:id/messages. Similarly, the /topic/:id/message/:sequencenumberAPI was removed in favor of its plural form /topics/:id/messages/:sequencenumber. Please update accordingly.topicRunningHashVersion to the transaction record. This change was necessary as the way the topic running hash is changing with the release of 0.5.0. As a result, the Hedera Mirror Node added this new field to its database and a migration is ran to populate it with either the new or old version depending upon the release date of 0.5.0.hedera.mirror.topicRunningHashV2AddedTimestamp to control this behavior and will fail on startup if this is not populated. This is just a temporary measure. Once Hedera Node 0.5.0 is released to testnet and mainnet we will update this so it's automatically populated with the known date.Transaction and TransactionRecord protobuf to a message queue for external consumption. We've also added REST API metrics and added Traefik as an API gateway for our helm chart./api/v1/topics/:id alpha REST API that was added in 0.9 has been changed to /api/v1/topics/:id/messages. This change was made to align the API with the other topic message APIs as it refers to the messages entity and not the topic entity.GET /api/v1/topic/7?sequencenumber=gt:2×tamp=lte:1234567890.000000006&limit=2/api/v1/topic/message/${consensusTimestamp} to retrieve a topic message by its consensus timestamp. Secondly, we added /api/v1/topic/${topic}/message/${seqNum} to retrieve a particular topic message by its sequence number from a topic. These APIs are considered alpha and may changed or be removed in the future. We also dramatically increased test coverage for the REST APIs and squashed some bugs in the process.hedera.mirror.parser.balance.keepFiles and hedera.mirror.parser.record.keepFiles to true.hedera.mirror.parser.record.persistTransactionBytes to hedera.mirror.parser.record.persist.transactionBytes. Please update your local configuration accordingly.