ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-01-29 15:43:55 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Fix typos (#4317)

Browse Source
This commit is contained in:
Katarzyna Streich 2018-12-03 22:30:15 +00:00 committed by Shams Asari
parent c03ad5abc3
commit 9232b3637b
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
core/src/main/kotlin/net/corda/core/flows/FinalityFlow.kt
View File

@ -23,7 +23,7 @@ import net.corda.core.utilities.ProgressTracker
*
* A list of [FlowSession]s is required for each non-local participant of the transaction. These participants will receive
* the final notarised transaction by calling [ReceiveFinalityFlow] in their counterpart flows. Sessions with non-participants
* can also be included, but they must specifiy [StatesToRecord.ALL_VISIBLE] for statesToRecortd if they wish to record the
* can also be included, but they must specify [StatesToRecord.ALL_VISIBLE] for statesToRecord if they wish to record the
* contract states into their vaults.
*
* The flow returns the same transaction but with the additional signatures from the notary.
@ -34,7 +34,7 @@ import net.corda.core.utilities.ProgressTracker
* @param sessions A collection of [FlowSession]s who will be given the notarised transaction. This list **must** include
* all participants in the transaction (excluding the local identity).
*/
// To maintain backwards compatibility with the old API, FinalityFlow can act both as an intiating flow and as an inlined flow.
// To maintain backwards compatibility with the old API, FinalityFlow can act both as an initiating flow and as an inlined flow.
// This is only possible because a flow is only truly initiating when the first call to initiateFlow is made (where the
// presence of @InitiatingFlow is checked). So the new API is inlined simply because that code path doesn't call initiateFlow.
@InitiatingFlow
@ -198,7 +198,7 @@ class FinalityFlow private constructor(val transaction: SignedTransaction,
*
* @param otherSideSession The session which is providing the transaction to record.
* @param expectedTxId Expected ID of the transaction that's about to be received. This is typically retrieved from
* [SignTransactionFlow].
* [SignTransactionFlow]. Setting it to null disables the expected transaction ID check.
* @param statesToRecord Which transactions to commit to the vault. Defaults to [StatesToRecord.ONLY_RELEVANT].
*/
class ReceiveFinalityFlow @JvmOverloads constructor(val otherSideSession: FlowSession,

2
docs/source/tut-two-party-introduction.rst
View File

@ -7,7 +7,7 @@ In the Hello, World tutorial, we built a CorDapp allowing us to model IOUs on le
elements:
* An ``IOUState``, representing IOUs on the blockchain
* An ``IOUFlow`` and ``IOFlowResponder`` flow pair, orchestrating the process of agreeing the creation of an IOU on-ledger
* An ``IOUFlow`` and ``IOUFlowResponder`` flow pair, orchestrating the process of agreeing the creation of an IOU on-ledger
However, our CorDapp did not impose any constraints on the evolution of IOUs on the blockchain over time. Anyone was free
to create IOUs of any value, between any party.