              :choices :any
              :tags [:fault-tolerance]
              :restrictions ["Must resolve to a function on the classpath at runtime."]
-             :optional? true}
+             :optional? true
+             :added "0.8.0"}
 
             :onyx/params
             {:doc "A vector of keys to obtain from the task map, and inject into the parameters of the function defined in :onyx/fn."
              :type :vector
              :tags [:function]
-             :optional? true}
+             :optional? true
+             :added "0.8.0"}
 
             :onyx/medium
             {:doc "Denotes the kind of input or output communication or storage that is being read from or written to (e.g. `:kafka` or `:web-socket`). This is currently does not affect any functionality, and is reserved for the future."

             :tags [:aggregation :grouping :windows :function]
             :optionally-allowed-when ["`:onyx/type` is set to `:function` or `:output`"]
             :restrictions ["Cannot be defined when `:onyx/group-by-key` is defined."
                            "`:onyx/flux-policy` must also be defined in this catalog entry."]}

            :onyx/bulk?
            {:doc "Boolean value indicating whether the function in this catalog entry denoted by `:onyx/fn` should take a single segment, or the entire batch of segments that were read as a parameter. When set to `true`, this function's return value is ignored. The segments are identically propogated to the downstream tasks."
             :type :boolean
             :default false
             :tags [:function]
             :optionally-allowed-when ["`:onyx/type` is set to `:function`"]}

            :onyx/flux-policy
            {:doc "The policy that should be used when a task with grouping enabled loses a peer. Losing a peer means that the consistent hashing used to pin the same hashed values to the same peers will be altered. Using the `:kill` flux policy will kill the job. This is useful for jobs that cannot tolerate an altered hashing strategy. Using `:continue` will allow the job to continue running. With `:kill` and `:continue`, new peers will never be added to this job. The final policy is `:recover`, which is like `:continue`, but will allow peers to be added back to this job to meet the `:onyx/min-peers` number of peers working on this task concurrently."

             :tags [:input :plugin :latency :fault-tolerance]
             :units :milliseconds
             :optionally-allowed-when ["`:onyx/type` is set to `:input`"
                                       "Value must be greater than 0."]
             :added "0.8.0"}

            :onyx/max-pending
            {:doc "The maximum number of segments that a peer executing an input task will allow in its internal pending message pool. If this pool is filled to capacity, it will not accept new segments - exhibiting backpressure to upstream message produces."
