I have a Read/Write Tasklet. In the writer, I am calling a Webservice that can fail. I am treating this as a Skippable Error condition. This is done because, we want to make use of the BATH_STEP_EXECUTION DB Table to know how many got processed and how many got skipped.

The problem is that the Batch API does resubmit failed ones by default. Tried to override the behavior as follows but still not working.

Tried NeverRetryPolicy as the retry-policy for the chunk. Created a custom policy similar to SimpleRetryPolicy (minus maxAttempts).
Code:
		<batch:step id="start-recall">
			<batch:tasklet task-executor="taskExecutor"
				throttle-limit="30">
				<batch:chunk reader="listReader" writer="policyWriter"
					commit-interval="1" retry-limit="1" skip-limit="100" retry-policy="myRetryPolicy">
					<batch:retryable-exception-classes>
						<batch:include
							class="com.pcg.batch.exception.SystemUnavailableException" />
					</batch:retryable-exception-classes>
					<batch:skippable-exception-classes>
						<batch:include class="java.lang.Exception" />
						<batch:include class="java.lang.NullPointerException" />
					</batch:skippable-exception-classes>
					
				</batch:chunk>
				<batch:no-rollback-exception-classes>
				<batch:include class="java.lang.NullPointerException"/>
				</batch:no-rollback-exception-classes>
			</batch:tasklet>
Also, tried AOP on the writer's write method as mentioned in the document.
Code:
	<bean id="retryAdvice"
		class="org.springframework.batch.retry.interceptor.RetryOperationsInterceptor">
		<property name="retryOperations" ref="retryTemplate" />
	</bean>
	<bean id="retryTemplate" class="org.springframework.batch.retry.support.RetryTemplate">
		<property name="retryPolicy" ref="myRetryPolicy" />
	</bean>
	<aop:config>
		<aop:pointcut id="transactional"
			expression="execution(* com..*PolicyItemWriter.write(..))" />
		<aop:advisor pointcut-ref="transactional" advice-ref="retryAdvice"
			order="-1" />
	</aop:config>
	<bean id="myRetryPolicy" class="com.pcg.batch.retry.policy.PCGRetryPolicy">
		<constructor-arg type="java.util.Map">
			<map>
				<entry key="java.lang.Exception" value="false" />
				<entry key="java.lang.NullPointerException" value="false" />
			</map>
		</constructor-arg>
	</bean>
Even that is not working.

In the logs, I notice that the Custom Policy is being invoked but the default behavior (SimpleRetryPolicy is referred at the Tasklet level),

Code:
PolicyItemWriter.write(PolicyItemWriter.java:88)] [taskExecutor-2] Error processing Policy PAP0098485
.PCGRetryPolicy.canRetry(PCGRetryPolicy.java:26)] [taskExecutor-2] Custom RetryPolicy Canretry .................. false
retry.support.RetryTemplate.doExecute(RetryTemplate.java:261)] [taskExecutor-2] Checking for rethrow: count=1
retry.support.RetryTemplate.doExecute(RetryTemplate.java:263)] [taskExecutor-2] Rethrow in retry for policy: count=1
core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:388)] [taskExecutor-2] Applying contribution: [StepContribution: read=1, written=0, filtered=0, readSkips=0, writeSkips=0, processSkips=0, exitStatus=EXECUTING]
core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:420)] [taskExecutor-2] Rollback for RuntimeException: org.springframework.batch.core.step.item.ForceRollbackForWriteSkipException: Force rollback on skippable exception so that skipped item can be located.
repeat.support.RepeatTemplate.doHandle(RepeatTemplate.java:291)] [main] Handling exception: org.springframework.batch.core.step.item.ForceRollbackForWriteSkipException, caused by: org.springframework.batch.core.step.item.ForceRollbackForWriteSkipException: Force rollback on skippable exception so that skipped item can be located.
core.step.item.SimpleRetryExceptionHandler.handleException(SimpleRetryExceptionHandler.java:85)] [main] Handled non-fatal exception
I guess the policy should be set at Tasklet level but do not know how - as in the Documentation, calling the RetryTemplate and setting the RepeatStatus.
Note: Seen similar questions in the forum but did not help my usecase.
Thanks