Module com.hedera.hashgraph.sdk
Package com.hedera.hashgraph.sdk.proto

Class ScheduleServiceGrpc.ScheduleServiceBlockingStub

java.lang.Object
io.grpc.stub.AbstractStub<ScheduleServiceGrpc.ScheduleServiceBlockingStub>
io.grpc.stub.AbstractBlockingStub<ScheduleServiceGrpc.ScheduleServiceBlockingStub>
com.hedera.hashgraph.sdk.proto.ScheduleServiceGrpc.ScheduleServiceBlockingStub
Enclosing class:
ScheduleServiceGrpc
public static final class ScheduleServiceGrpc.ScheduleServiceBlockingStub extends io.grpc.stub.AbstractBlockingStub<ScheduleServiceGrpc.ScheduleServiceBlockingStub>
A stub to allow clients to do limited synchronous rpc calls to service ScheduleService. 

 Transactions and queries for the Schedule Service.<br/>
 The Schedule Service enables transactions to be submitted without all
 required signatures and offers a `scheduleSign` transaction to provide
 additional signatures independently after the schedule is created. The
 scheduled transaction may be executed immediately when all required
 signatures are present, or at expiration if "long term" schedules
 are enabled in network configuration.
 ### Execution
 Scheduled transactions SHALL be executed under the following conditions.
 1. If "long term" schedules are enabled and `wait_for_expiry` is set for
    that schedule then the transaction SHALL NOT be executed before the
    network consensus time matches or exceeds the `expiration_time` field
    for that schedule.
 1. If "long term" schedules are enabled and `wait_for_expiry` is _not_ set
    for that schedule, then the transaction SHALL be executed when all
    signatures required by the scheduled transaction are active for that
    schedule. This MAY be immediately after the `scheduleCreate` or a
    subsequent `scheduleSign` transaction, or MAY be at expiration if
    the signature requirements are met at that time.
 1. If "long term" schedules are _disabled_, then the scheduled transaction
    SHALL be executed immediately after all signature requirements for the
    scheduled transaction are met during the `scheduleCreate` or a subsequent
    `scheduleSign` transaction. The scheduled transaction SHALL NOT be
    on expiration when "long term" schedules are disabled.
 A schedule SHALL remain in state and MAY be queried with a `getScheduleInfo`
 transaction after execution, until the schedule expires.<br/>
 When network consensus time matches or exceeds the `expiration_time` for
 a schedule, that schedule SHALL be removed from state, whether it has
 executed or not.<br/>
 If "long term" schedules are _disabled_, the maximum expiration time SHALL
 be the consensus time of the `scheduleCreate` transaction extended by
 the network configuration value `ledger.scheduleTxExpiryTimeSecs`.
 ### Block Stream Effects
 When a scheduled transaction is executed, the timestamp in the transaction
 identifier for that transaction SHALL be 1 nanosecond after the consensus
 timestamp for the transaction that resulted in its execution. If execution
 occurred at expiration, that transaction may be almost any transaction,
 including another scheduled transaction that executed at expiration.<br/>
 The transaction identifier for a scheduled transaction that is executed
 SHALL have the `scheduled` flag set and SHALL inherit the `accountID` and
 `transactionValidStart` values from the `scheduleCreate` that created the
 schedule.<br/>
 The `scheduleRef` property of the record for a scheduled transaction SHALL
 be populated with the schedule identifier of the schedule that executed.

  • Method Details

    • build

      protected ScheduleServiceGrpc.ScheduleServiceBlockingStub build(io.grpc.Channel channel, io.grpc.CallOptions callOptions)
      Specified by:
      build in class io.grpc.stub.AbstractStub<ScheduleServiceGrpc.ScheduleServiceBlockingStub>

    • createSchedule

      public TransactionResponse createSchedule(Transaction request)
      
 Create a new Schedule.
 <p>
 If all signature requirements are met with this transaction, the
 scheduled transaction MAY execute immediately.

    • signSchedule

      public TransactionResponse signSchedule(Transaction request)
      
 Add signatures to an existing schedule.
 <p>
 Signatures on this transaction SHALL be added to the set of active
 signatures on the schedule, and MAY result in execution of the
 scheduled transaction if all signature requirements are met.

    • deleteSchedule

      public TransactionResponse deleteSchedule(Transaction request)
      
 Mark an existing schedule deleted.
 <p>
 Once deleted a schedule SHALL NOT be executed and any subsequent
 `scheduleSign` transaction SHALL fail.

    • getScheduleInfo

      public Response getScheduleInfo(Query request)
      
 Retrieve the metadata for a schedule.