Skip to content

Shard Controller life-cycle bug fix#1

Merged
tamer-eldeeb merged 2 commits intocadence-workflow:masterfrom
samarabbas:shard-controller-lifecycle-fix
Feb 22, 2017
Merged

Shard Controller life-cycle bug fix#1
tamer-eldeeb merged 2 commits intocadence-workflow:masterfrom
samarabbas:shard-controller-lifecycle-fix

Conversation

@samarabbas
Copy link
Contributor

We were not setting the shardID on shardContext when the shard is
acquired by a host. This caused the shardID to be intialized to 0 for
all shards. We used the same shardID for sending the closed event on
the shardClosedCh which caused us to always remove the shardID 0.

Updated onebox setup to have support for spinning up multiple history
hosts. Also changed the integration tests to use 2 history hosts for
running the tests.

Also made some minor logging fixes.

We were not setting the shardID on shardContext when the shard is
acquired by a host.  This caused the shardID to be intialized to 0 for
all shards.  We used the same shardID for sending the closed event on
the shardClosedCh which caused us to always remove the shardID 0.

Updated onebox setup to have support for spinning up multiple history
hosts.  Also changed the integration tests to use 2 history hosts for
running the tests.

Also made some minor logging fixes.
Remove redundant tag to add hostname on service startup.
Change the number of history hosts to 1 due to data race issue.
@samarabbas samarabbas self-assigned this Feb 22, 2017
@samarabbas samarabbas added the bug label Feb 22, 2017
@tamer-eldeeb tamer-eldeeb merged commit 6d2a923 into cadence-workflow:master Feb 22, 2017
@samarabbas samarabbas deleted the shard-controller-lifecycle-fix branch February 22, 2017 17:33
wxing1292 pushed a commit that referenced this pull request Sep 18, 2019
c-warren added a commit that referenced this pull request Sep 30, 2025
<!-- Tell your future self why have you made these changes -->
**Why?**

Our existing commit process:
- doesn't immediately convey when there are breaking changes to the
releaser
- doesn't provide information about how to categorize changes in each
release
- is entirely manual preparing releases
- doesn't always give "good" information about what is contained within
a commit
- doesn't give a good idea of the risk of a given commit 

Furthermore, users have stated that our release notes do not provide
easily discernable information about what is in a release, including:
- if there are breaking changes
- which features are in a given release 
- why they should upgrade

Adding conventional commits aims to tackle these pieces and make
contributing to the repository significantly easier.

This PR adds a linter that will give feedback to developers on their
commit message style, and will eventually enforce conventional commits
for each merge PR.

<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**

Currently testing. 

<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**

Adding this GitHub action may have unintended consequences for the
commit process, and should be monitored to ensure that it doesn't
inhibit merging to the repository.

<!-- Is it notable for release? e.g. schema updates, configuration or
data migration required? If so, please mention it, and also update
CHANGELOG.md -->
**Release notes**

N/A

<!-- Is there any documentation updates should be made for config,
https://cadenceworkflow.io/docs/operation-guide/setup/ ? If so, please
open an PR in https://github.com/cadence-workflow/cadence-docs -->
**Documentation Changes**

⚠️ TODO
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants