# NuVotifier tasks

Task guides and troubleshooting for NuVotifier. Check the installed release before changing configuration or data.

# Stop duplicate vote rewards caused by two forwarding paths

A player receiving two rewards may have two delivery paths rather than a reward file that runs twice. NuVotifier can forward votes itself, while VotingPlugin also supports its own proxy transport. Combining both without a deliberate design can submit the same event twice.

## Before you change settings

Draw the route from the voting website to the public receiver, proxy transport, backend listener and reward plugin. Record installed builds and save configurations before making a change. Choose one test player and a quiet period so separate legitimate votes are not mistaken for duplicates.

## Follow the request through the plugin

1. Send one real test from a configured listing and record its timestamp and service identifier. Compare receiver and reward logs across the proxy and destination backend; do not resend until the first attempt is understood.
2. Identify which component owns forwarding. For the documented standard VotingPlugin proxy layout, follow its transport guide and keep NuVotifier backend forwarding disabled. A NuVotifier-only forwarding layout has different requirements.
3. Check for another public receiver, duplicate listener plugin or a second destination entry. Disable only the redundant route after confirming the retained route can reach the intended reward processor.
4. Restart affected components in a planned window and send one further controlled vote. Check the receiver count, processing count, balance change and item delivery separately.

## Confirm the intended result

One external vote should create the expected number of deliveries under your declared network policy. If every backend should receive it, distinguish that intentional fan-out from two rewards on the same backend. Test a player who changes backend as well as one who stays connected.

## If the test fails

If duplicate rewards persist after only one event reaches VotingPlugin, inspect reward configuration, milestone triggers and repeated command entries. A first-vote bonus alongside a normal reward may be intentional; record each reward source before removing it.

Restore the previous forwarding settings if the retained route fails. Keep vote history and evidence intact. Reconcile accidental rewards with the owner rather than clearing totals or replaying a day of votes to repair one routing mistake.

## Sources and related help

- [NuVotifier maintainer reference 1](https://github.com/NuVotifier/NuVotifier/wiki/Setup-Guide)
- [NuVotifier maintainer reference 2](https://wiki-backup.bencodez.com/VotingPlugin/Votifier-Troubleshooting/)
- [Configure NuVotifier and protect vote-receiver credentials](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/configure-nuvotifier-and-protect-vote-receiver-credentials)

# Find an offline vote waiting in NuVotifier forwarding cache

A received vote can wait for a suitable delivery route. With NuVotifier plugin-messaging forwarding, the configured fallback affects where an offline player’s vote eventually goes. A queued event is not proof that the listing failed to send it.

## Before you change settings

Record whether the network uses NuVotifier plugin messaging or a different plugin’s proxy transport. This procedure concerns NuVotifier’s own cache. Save forwarding settings and note one test vote’s player, service identifier and timestamp before testing reconnect behaviour.

## Follow the request through the plugin

1. Verify the proxy received the vote, then inspect whether forwarding is limited to the joined server. Identify the configured `joinedServerFallback` and excluded destinations.
2. If a fallback is configured, check whether it is reachable. The maintainer guide explains that a cached vote awaiting that fallback is not automatically redirected to whichever server the player next joins.
3. If your intended policy is delivery on the next join, compare the documented empty fallback arrangement with the current configuration. Change the policy only after understanding votes already queued under the old route.
4. Check the configured cache retention and storage type. Reconnect the test player once, follow the receiver and backend logs, and wait for the recorded vote to be delivered before sending another.

## Confirm the intended result

The event should arrive at the destination chosen by your forwarding policy, within the configured retention window. Record which backend applied the reward. Confirm normal online delivery still works after adjusting an offline route.

## If the test fails

A listener accepting the event and a reward plugin queuing an offline reward are different stages. If the backend already processed the vote, troubleshoot that plugin’s reward queue instead. Do not assume every proxy or forwarding method has NuVotifier’s caching behaviour.

Restore the previous fallback setting if the new policy sends events to an unintended backend. Preserve cache files and vote logs. Do not delete the cache or manually replay all votes while previously accepted events may still be pending.

## Sources and related help

- [NuVotifier maintainer reference 1](https://github.com/NuVotifier/NuVotifier/wiki/Setup-Guide)
- [Configure NuVotifier and protect vote-receiver credentials](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/configure-nuvotifier-and-protect-vote-receiver-credentials)

# Correct a vote listing that uses the wrong token or RSA key

NuVotifier’s legacy RSA credentials and newer protocol tokens are different. Supplying a token where a listing expects a public key can fail even when the receiver port is reachable. Verify the listing’s supported protocol before replacing any credentials.

## Before you change settings

Identify the exact public receiver and save its configuration privately. Record the listing, configured hostname, assigned port and selected protocol. Never paste an entire listener configuration into a public ticket: it can contain secrets for other routes.

## Follow the request through the plugin

1. Check the listing’s supported Votifier version and its credential field. Legacy RSA setup uses the receiver’s public key; the matching private key remains on the server.
2. For a token-based integration, select the token intended for that public receiver. Do not substitute a backend forwarding token simply because both are short strings.
3. Confirm the listing connects to the real public address and allocated listener port. A wildcard bind address such as `0.0.0.0` is not a destination to enter on the listing website.
4. Save the corrected listing details and send one listing-generated test. Compare its timestamp with NuVotifier logs, then follow the accepted event through the reward listener.

## Confirm the intended result

The receiver should accept the external event and the intended player should receive the configured reward once. Check a second independently configured listing without overwriting its credentials; different integrations can use different supported methods.

## If the test fails

If no connection appears, investigate endpoint reachability before rotating keys. If a connection is rejected, inspect protocol and credential mismatch. A successful local reward command does not authenticate a remote listing or test its network route.

Restore the previous listing entry if you changed the wrong receiver. If a token or private key was exposed, coordinate replacement of that credential and its dependent integrations. Keep unrelated credentials and player vote history intact.

## Sources and related help

- [NuVotifier maintainer reference 1](https://github.com/NuVotifier/NuVotifier/wiki/Setup-Guide)
- [Configure NuVotifier and protect vote-receiver credentials](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/configure-nuvotifier-and-protect-vote-receiver-credentials)

# Separate an accepted vote from a failed reward listener

NuVotifier receives vote records; it does not include a reward listener by default. A website’s successful test can therefore stop at the receiver while the player sees no coins, items or message. Establish which stage actually completed.

## Before you change settings

Write down the receiver process, reward plugin and backend where delivery is expected. Save the test player’s starting balance and inventory if rewards modify them. Use a genuine account identity and one configured listing to avoid confusing an invented username with a delivery failure.

## Follow the request through the plugin

1. Send one external test and capture the receiver’s timestamp and accepted vote details. If no receiver event exists, stop here and check the listener endpoint, allocation and listing credentials.
2. Confirm a compatible reward listener is loaded on the process that receives or legitimately forwards the event. Read startup errors rather than assuming the presence of its JAR means it is active.
3. Look for the reward plugin’s receipt of the same player and service identifier. On a network, follow the forwarding stage between the proxy and backend before editing reward amounts.
4. If receipt is confirmed, inspect site matching, eligibility, offline queues and the particular reward action. Run a bounded local processing test only to isolate that downstream stage.

## Confirm the intended result

A complete test should show receipt, processing and the intended player-visible result. Record each stage separately so a future support report identifies the missing link. Verify the player reconnects normally if the reward requires online delivery.

## If the test fails

An administrative local vote can pass while the public listener is unreachable. Conversely, an accepted listener event can fail to match a configured service name. Do not treat either test as proof of the whole chain or repeatedly send rewards while diagnosis is incomplete.

Revert the single listener or reward setting you changed if another working site stops processing. Preserve event logs and queued records. Do not reinstall the server or erase vote data to resolve a missing listener hook.

## Sources and related help

- [NuVotifier maintainer reference 1](https://github.com/NuVotifier/NuVotifier/wiki/Setup-Guide)
- [NuVotifier maintainer reference 2](https://wiki-backup.bencodez.com/VotingPlugin/Votifier-Troubleshooting/)
- [Configure NuVotifier and protect vote-receiver credentials](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/configure-nuvotifier-and-protect-vote-receiver-credentials)